Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's a specific niche where this kind of technology makes quite good sense, although it looks like the current focus is primarily B2C.

With the sheer number of exploits against complex attack surface web browsers, I could see organisations using this to mostly eliminate use of the web browser locally. If you can get a trusted, audited provider to host remote cloud browser instances that ship with "always on" policy enforcement (ad blocking, site blocking, phishing filtering, data loss prevention etc.), you can move all web activity to another system in the cloud. You can erase and have new instances set up as needed (daily?).

Web browsing locally would then be restricted by firewalls to only work on high security local systems (which themselves are not pulling in any external dependencies) - you could eventually lock the local browser down to only speak to a very limited internal IP range.

While this won't work for risk taking internet-first organisations, there's governments and enterprise users who would love something like this, as it helps them reduce their risk exposure on client devices - as long as the remote video and input protocol is robust and memory safe, it starts to become incredibly difficult for a lot of attacks to succeed against their protected systems. This also potentially removes the need in some cases for people to carry 2 laptops - one for higher security activities, one for public internet level activities. If this software can be assured to a suitable level and isolated appropriately, it could be an interesting solution to a very boring problem!



This is likely the target for the product. Still, at a relatively small number of seats, maybe 200? an IT service administrating Chrome through the Google Apps service you're likely already paying for becomes more economical.


I'd probably agree with that, but for high assurance use cases, this is probably still incredibly attractive. Being able to ensure JavaScript and other web content isn't executing in your network, and the link out to that system is understood and risk managed could be powerful for them.

Keeping public internet work separate from local webapps would certainly help to avoid a fair number of vulnerability classes (as public browsing would take place in a totally separate environment without filesystem access or access to local resources, without access to local credentials, cookies, or network resources).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: