5 ms·

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 hav

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?

mwcampbell 5y ago
As it turns out, the CEO has already responded [1], and I feel bad that we (myself included) made him feel that he had to rush it. [1]: https://news.ycombinator.com/item?id=28031787 https://news.ycombinator.com/item?id=28031787
- deleted 5y ago
  [deleted]
- eastdakota 5y ago
  Copied here for visibility… === 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.
  - mwcampbell 5y ago
    > 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. [1]: https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/ https://blog.cloudflare.com/cloudflare-and-remote-browser-is... [2]: https://blog.cloudflare.com/browser-isolation-for-teams-of-all-sizes/ https://blog.cloudflare.com/browser-isolation-for-teams-of-a... [3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1055393 https://bugs.chromium.org/p/chromium/issues/detail?id=105539...

mwcampbell 5y ago

As it turns out, the CEO has already responded [1], and I feel bad that we (myself included) made him feel that he had to rush it. [1]: https://news.ycombinator.com/item?id=28031787 https://news.ycombinator.com/item?id=28031787

deleted 5y ago
[deleted]
eastdakota 5y ago
Copied here for visibility… === 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.
- mwcampbell 5y ago
  > 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. [1]: https://blog.cloudflare.com/cloudflare-and-remote-browser-isolation/ https://blog.cloudflare.com/cloudflare-and-remote-browser-is... [2]: https://blog.cloudflare.com/browser-isolation-for-teams-of-all-sizes/ https://blog.cloudflare.com/browser-isolation-for-teams-of-a... [3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1055393 https://bugs.chromium.org/p/chromium/issues/detail?id=105539...