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

Mozilla really needs to add its own sandboxing system. Even Chris Soghoian from ACLU says that right now it's hard to simply recommend Firefox over Chrome, because Firefox may be better privacy wise, but it's not better security wise.


Indeed. It's the only reason I stick with chrome even though I desperately want to find an alternative. I cringe every time mozilla launches yet another overly ambitious project while their market share in their core product continues to decline and glaring issues with their browser persist. I don't know how their strategy will play out for them but I'm not optimistic.



And it's already enabled in Firefox OS on devices that have seccomp support in their kernel.


You can try Firefox's sandbox code (work in progress) in Firefox Nightly channel (30). Then invoke the File > New e10s Window command. No about config magic.


I use Nightly and I hadn't noticed that, so I tried it; an alert opened:

> To use out-of-process tabs, you must set the layers.offmainthreadcomposition.enabled preference and restart. Opening a normal window instead.

So it does actually require a about:config tweak to enable it.


Sorry, I forgot that Linux and Windows need off-main-thread composition (OMTC), which is already enabled by default on OS X.

* Linux OMTC: https://bugzil.la/722012 * Windows OMTC: https://bugzil.la/913249


A sandbox is just code and code has bugs. As was said in the article you can escape the sandbox.


That's like saying locks are one more thing that can be broken, just like the doors. So why do people have locks on doors - in security you put up as many deterrents as practical and hope one of them saves the day. It's generally worth it.


That's actually the point of a sandbox. Code has bugs, so you sandbox it.

Now, the sandbox is also code, but to my understanding it's fewer LoC than what you are sandboxing. As bug rate per LoC is a fairly stable value, reducing LoC reduces total bug count. Ergo, by wrapping a large complex program with many LoC inside a small sandboxing function, you increase security (though it is not perfect, it still will have SOME bugs)


The amount of unsandboxed code in Chromium is not a whole lot smaller (if at all) than the amount of sandboxed code on a lines-of-code basis. The advantage of sandboxing is that most of the code that directly interacts with content (the rendering engine) is prevented from directly performing malicious actions, assuming the sandbox is secure.


I don't think "security" is usually a binary concept, where it's either there or it isn't. It's more useful to draw an analog from the ratings of safes, which are along the lines of "it would take ___ hours / days to break this safe." Instead of lofty claims about being impervious to attack, put up obstacles and hurdles, that make attacks harder.


But those "obstacles" and "hurdles" can themselves be exploited in some cases. If they're software-based, then they can just end up making the attack surface much larger.


So we are down to a "choose your favourite rapist" situation.




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

Search: