First up that is some great feedback and raises a lot of really good points.
I don't know if you're missing anything but this feedback about files is on point. I really appreciate it. And I'm surprised no one raise this until now. Thank you for your time thinking about this and for making the space for me to speak about it.
> Users need to download files, open them with local apps, upload local files.
Ideally, user's don't download files, they use the Secure remote file viewer[0] (which currently handles PDFs, DOC/X, XLSX, etc), so that helps with exploits from there (such as the Chrome zero day from PDFium that recently occurred). No configuration is required, it automatically jumps in whenever a download starts.
Also, because the browser is running in the cloud, that "download" actually only happens between the web and the cloud. The file literally goes down to a temporary directory on a server in the cloud, before being sent to the secure file viewer. That file never touches the client's device or network. And the secure file viewer only sends pixels to the client, because it converts all documents to images, and then, the browser sends a screenshot of that page. So it's like... two layers of images.
Anyway, that helps mitigate the RCE threat from exploited file objects, browser and device zero days. And no HTML,JS,CSS from the browsed page is ever sent to your device.
As for opening with local apps, that's debatable with things like G Suite and Office 365. But we can integrate with a corporation's SWG (secure web gateway) and file policy so BG doesn't degrade their existing security, but it does provide an extra layer.
As for uploading that is absolutely required, otherwise many things would be unusable. I don't pretend that BG provides any sort of malware or virus scanner (mainly because there is not download), but as for uploads, it's possible to integrate into an organizations' existing SWG technology to gate-keep content that leaves, and also white and black list accessible sites.
> Current malware codebase might get stuck with it, but it's a matter of time and adoption.
I agree that to some extent, security is an ongoing "arms race". But there seems to be limits to what malware can achieve through the exploitation of pixels sent to the device. It puts a big limit on their attack vectors.
It sounds like there's no point taking any steps, because malware can always find a way through. When you say something like this, I feel like I'm wasting my time talking security, because it looks like you'd never adopt a mitigation anyway.
> Other threats like clickjacking, cryptomining, phishing would just work as before.
That's a great point. I don't think this tool can prevent against social engineering threats like phishing, fraud and deception. It may even may them worse by allowing users to feel "more secure" and therefore act more rashly.
No tool provides perfect protection, but BG can reduce the attack surface and isolate and contain many threats away from the device and network of the client. In the case of clickjacking, older browsers can be vulnerable because of CSP headers, but with BG you always proxy through the latest chrome.
As for cryptomining that will simply not work well at all. We have monitoring software that puts hard limits on CPU, memory and bandwidth for each browser and each user. Please, go ahead and try it.
[0]: https://imgur.com/gallery/Z32ZPg3