It's a public company and there's probably only a few people who would be authorised and feel comfortable to speak on behalf of their employer. Most of them have been working hard building the company for years and shouldn't be expected to be on call for a non-production related concern being raised on HN on any given Sunday.
Cloudflare's management is exemplary when it comes to transparent comms, maybe we can wait a day for their response on this one?
This has been prioritized since long before Matt emailed me. It was specifically flagged during our diligence process of S2 Systems, the company we acquired for the Remote Browser Isolation (RBI) technology. It has been an engineering project that I have personally followed since we acquired S2 nearly two year ago.
Unfortunately, this has proved a non-trivial problem to solve, in spite of significant engineering resources dedicated to it, and we don't yet have an acceptable solution. But I'm confident we're on the right track.
The challenge is that the process of rendering content inert to local security threats also makes it also not compatible with current screen reader technology. Matt has helpfully suggested some ideas which are in-line with what we have been working on, but the diversity of the web makes the solution very complex in practice. While I appreciate his suggestion in this thread that if we would just hire him this could be fixed in a few months, I think he would acknowledge upon reflection that is flippant.
How the web is rendered and the diversity of web pages, especially dynamically updated pages, makes many solutions that seem obvious not tenable. We need to validate the solution we deliver will work across all the complexities of the web and across a broad range of accessibility devices while, at the same time, not introducing new threats. We already have a great team doing this work. RBI is still a new product for us, and it's only been recently that we've gotten the core technology to work to a level that's acceptable, but I'm confident with the work we're doing we will be the first RBI technology in the market with broad accessibility support.
In the meantime, we provide our customers a way to bypass the RBI technology to accommodate their visually impaired employees. In these cases, we recommend that additional safeguards be put in place for these employees' machines to guard against potential security compromise. This isn't a perfect solution, but it does help significantly reduce the surface area of attack while allowing visually impaired employees to do their jobs.
I hope that others in the space with similar technologies — including Mighty, Menlo Security, zScaler, and others — will also dedicate the resources needed to make their products as accessible as possible. Matt is right to call on the industry to prioritize the needs of visually impaired users. As we solve these challenging problems ourselves, we will share what we've learned, how we overcame challenges, and we will not do anything to restrict the intellectual property behind the solutions so the entire industry can benefit.
As for the rest of the discussion in this thread, I agree that Cloudflare is fundamentally in the trust business. It takes 5 minutes to sign up for Cloudflare, but only seconds to leave. We need to earn the trust of our customers, as well as Internet users in general, on a daily basis or we won't have a business. Appreciate everyone holding us accountable to that.
> It was specifically flagged during our diligence process of S2 Systems, the company we acquired for the Remote Browser Isolation (RBI) technology. It has been an engineering project that I have personally followed since we acquired S2 nearly two year ago.
Then why is it that, as far as I can tell, Cloudflare hasn't publicly acknowledged the problem before now?
For example, the blog post announcing the acquisition of S2 said:
> (4) Transparent user experience: S2 remote browsing feels like native browsing; users are generally unaware when they are browsing remotely.
This is emphatically not the case for screen reader users, and there was no acknowledgement that that was a challenge yet to be solved. There was also no acknowledgement in the product launch blog post during Security Week [2], and I haven't been able to find any in public documentation, though perhaps I just haven't hit upon the right search term.
> How the web is rendered and the diversity of web pages, especially dynamically updated pages, makes many solutions that seem obvious not tenable. We need to validate the solution we deliver will work across all the complexities of the web and across a broad range of accessibility devices while, at the same time, not introducing new threats.
To be clear, I know why the more simplistic proposed solutions, which amount to sending down the original HTML or some sanitized version of it, would go against the goals for this product, particularly around security. I guess it's also plausible that my proposed solution, using the Chromium accessibility tree to reconstruct just enough of an HTML DOM to expose the needed information, would reopen some types of local browser escape exploits. Your team certainly knows way more about those vulnerabilities than I do.
Edit: OK, I'm convinced; I just found a report of a use-after-free vulnerability (now fixed) in Chromium accessibility code [3]. I guess I really didn't grasp how hard this is.
> In the meantime, we provide our customers a way to bypass the RBI technology to accommodate their visually impaired employees. In these cases, we recommend that additional safeguards be put in place for these employees' machines to guard against potential security compromise.
I'm sure the mechanism for configuring this bypass is documented. But does your documentation specifically call out the accessibility limitation of your product, the need for this workaround, and the recommended additional safeguards for these employees' machines?
> As we solve these challenging problems ourselves, we will share what we've learned, how we overcame challenges, and we will not do anything to restrict the intellectual property behind the solutions so the entire industry can benefit.
I hope that Cloudflare will not develop these solutions in a vacuum, but will consult with blind people who have the expertise to help ensure you're on the right track. I still offer my advice, free of charge; as I said in my other reply, my intent in the earlier comment with the rough time estimate wasn't to push for you to hire me. But enough about me; the point is that accessibility solutions developed for us shouldn't be developed without involving us.
On reflection, I think the real problem isn't how long it's taking to make the product accessible, but the fact that you went ahead and launched the product without an accessibility solution and with no public acknowledgement of the problem (as far as I can tell). I don't think it's right to sweep our needs under the rug like that.
> Edit: OK, I'm convinced; I just found a report of a use-after-free vulnerability (now fixed) in Chromium accessibility code [3]. I guess I really didn't grasp how hard this is.
Appreciate your understanding. We also understand how important this is. While we don't publicly discuss every challenge we struggle with, we're usually pretty good at finding solutions to hard but important problems. And this is clearly an important problem, and a hard one. Do hope you'll keep up the pressure on us — as well as others like Mighty, Menlo Security, and zScaler — to prioritize this. And, whatever the best solution, if we find it, we're committed to sharing it with the rest of the industry.
> we don't publicly discuss every challenge we struggle with
Of course. But that's not what I, and hundreds of thousands (or more) of other working blind people, are expecting of you. This isn't like blogging about some obscure network performance problem that the team has been struggling with. Instead, the team has been keeping decision-makers in the dark about something that's crucial for them to consider when evaluating this product. If decision-makers adopt the product without having this information about an important limitation, they may inadvertently prevent blind employees from doing their work. Even if the customer ends up making the accommodations you suggest for their blind employee(s), they currently have to be reactive about it. And in the meantime, the blind employees' productivity is disrupted, particularly if they weren't tech-savvy enough to diagnose their inability to do normal web browsing, as SLJ7 pointed out [1]. That's why Cloudflare has an obligation to publicly disclose this limitation in the product.
Also, I read just a few minutes ago that Cloudflare is partnering with Accenture Federal Services to start deploying some of your network security technology in the US federal government [2]. I know this is starting with your DNS service; so far, so good. But I'm sure you would like to offer your Browser Isolation product as well. That product is currently not in compliance with the relevant accessibility requirements for products that are sold to the federal government. I was reluctant to reach for that particular stick, but maybe it will give the team more motivation to solve this problem.
This seems a bit of a failure of communication. Let's be honest: we all know that "thanks for your suggestion, we take this very seriously!" is business speak for "yeah yeah, go away" more often than not. Even if Cloudflare is better than this (I don't know), it's still the industry average and context in which Cloudflare exists.
So if you want to show you're actually taking something serious a bit more signalling is needed. I don't think anyone really benefited that there's a team actually working on this was only communicated after this article.
naive question, but why can't you run the screen reader on the remote instance and wire key presses through? I do something similar when I need to remote desktop without using my hands - I install hunt-and-peck on the target machine, then I can say the hotkeys to bring it up and say letters to click things in the remote windows.
even if you have a crappy screen reader, it's better to throw your disabled users some kind of bone than to make them wait for some perfect solution that will never get properly funded.
I'm afraid I might be partially responsible for the lack of this work-around. In a phone conversation with the Browser Isolation product manager a few weeks before the product launch in March (but remember, well over a year after I first contacted Cloudflare about accessibility in this product), I articulated some version of the problems with a remote screen reader that I laid out in [1]. But I may not have emphasized enough that this would be better than nothing. Since it was a phone conversation and not an email exchange, I unfortunately have no record of what I said. Still, I can't take full responsibility for the fact that, to all outward appearances, they have done nothing about this problem so far.
> For blind people, TTS settings are very personal.
Is there a whitepaper that articulates concrete solutions to reconcile the myriad flavors of screen reader configurations with Browser Isolation technology?
the other issue is that while this would work for screen readers, it wouldn't work for me. I can see fine, but I'm losing the use of my arms, so I use vimium with dictation to navigate pages. they'd have to bake vimium into it as well...
...which suggests to me, why not allow approved browser extensions to run on the remote side? you could have a screen reader extension, I could have vimium, it wouldn't be great but it would be secure, and again, better than nothing.
Your suggestion is probably the correct solution technically speaking, as it funnels the screen reader I/O stream through browser APIs.
The immediate objection is that most popular screen readers (JAWS, NVDA) are native apps and not browser extensions, (some?) extension-based screen readers being immature. mwcampbell articulated it as much in a different post, asking for a native desktop client as opposed to a browser based client. Alas, 'native desktop client' is a different technology than Cloudflare RBI, subject to different tradeoffs, which may well be at odds with the goals of Cloudflare RBI as a product.
A hypothetical browser accessibility protocol is likely to prove insufficient, as native screen reader apps will themselves become an attack vector.
Unlocking the situation requires a wider industry buy-in beyond Cloudflare. Screen readers must be rearchitected with security in mind. IT departments must manage accessibility apps. Advocacy groups must commit to roadmaps that include a lot of change, and that may even degrade the status quo for many years to come. Given that existing screen reader apps have decades of engineering already poured in, it will be hard and expensive to enact change. A good early step could be creating an industry standard various entities can rally behind.
I've struggled with security vs. accessibility myself. my work won't allow my dictation software on the secure workstations we have to use, at least for the near future. they allow Dragon, but Dragon sucks for interaction and programming. companies can't just throw their hands up and say "security" though.. or at least they shouldn't. they can and do, I guess.
>I'm sure the mechanism for configuring this bypass is documented. But does your documentation specifically call out the accessibility limitation of your product, the need for this workaround, and the recommended additional safeguards for these employees' machines?
This is super important. Remember that while a bunch of us are nerds who know how computers work, some blind people might just know enough to use the web and do their job--as most people in the world do. They won't understand why the product doesn't work, let alone know how to fix it. The problem with a solution this transparent is that a request will have to go way up the chain before someone will actually know enough to address it and determine the problem. Of course it's not the job of Cloudflare to fix corporate ignorance, but a note like this one in the documentation might be a good start.
Also, it's worth noting that when using Browser Isolation with a screen reader, the product itself doesn't tell the user anything informative, e.g. through one of those off-screen messages that are sometimes added to websites specifically for screen reader users. Instead, the user gets a debug UI that isn't even visible on the screen, followed by an unlabeled graphic. So as far as anyone on the outside can tell (at least, before today's conversation), Cloudflare has done nothing about accessibility in this product.
Cloudflare's management is exemplary when it comes to transparent comms, maybe we can wait a day for their response on this one?