Multiprocess and sandboxing design: PALEMOON BROWSER AT A CROSSROADS.

[New Tobin Paradigm]

Everything the Main process can do the sub-processes can do.. The sandboxing you are mentioning applies to exactly what and how the processes can intercommunicate with each other. As for powers granted to content scripting vs chrome scripting that is a different matter. Though in an e10s setup it would need to obey interprocess communication.. But the processes talking to each other is not the same as the process talking to the system or the a fore mentioned powers granted to content and chrome.

Basically, your facts are uncoordinated.

[Moonchild]

Web content (web pages) operate in a separated environment inside the browser by design. This is essential for any web browser.
Without going into the technicalities of containers and wrappers, you can simply say that every website runs in its own individual sandbox. No, scripts won't have access to the file system. If that was possible then any malicious website could openly read all your files, overwite your data, or install software without you being any wiser.

The "perceived security" of web content running in its own process is assuming that this sandboxing mechanism fails or even worse, so people don't have to develop security-aware systems to contain page content because the process it runs in is (supposed to be) a restricted process (that in itself is also a fallacy because the elaborate communication between main process and content process has no guarantee of being flawless either, although it may make things slightly less straightforward once a script breaks out of its web content context). This is once again fighting a symptom, not the cause -- and assuming that the browser code isn't or can't be made secure on its own. Similar to assuming the browser would be crash-y. It follows the same vein there, focusing on picking up the pieces rather than preventing that things break to begin with.

[smolnyn]

Web content (web pages) operate in a separated environment inside the browser by design. This is essential for any web browser.
Without going into the technicalities of containers and wrappers, you can simply say that every website runs in its own individual sandbox. No, scripts won't have access to the file system. If that was possible then any malicious website could openly read all your files, overwite your data, or install software without you being any wiser.

The "perceived security" of web content running in its own process is assuming that this sandboxing mechanism fails or even worse, so people don't have to develop security-aware systems to contain page content because the process it runs in is (supposed to be) a restricted process (that in itself is also a fallacy because the elaborate communication between main process and content process has no guarantee of being flawless either, although it may make things slightly less straightforward once a script breaks out of its web content context). This is once again fighting a symptom, not the cause -- and assuming that the browser code isn't or can't be made secure on its own. Similar to assuming the browser would be crash-y. It follows the same vein there, focusing on picking up the pieces rather than preventing that things break to begin with.

Thank you so much for all inclusive and light shows

[smolnyn]

Everything the Main process can do the sub-processes can do.. The sandboxing you are mentioning applies to exactly what and how the processes can intercommunicate with each other. As for powers granted to content scripting vs chrome scripting that is a different matter. Though in an e10s setup it would need to obey interprocess communication.. But the processes talking to each other is not the same as the process talking to the system or the a fore mentioned powers granted to content and chrome.

Basically, your facts are uncoordinated.

Forgive my ignorance, but I can not understand your explanation. Do you could re-explain in the simplest way for me? Thanks for the kindness.

[New Tobin Paradigm]

Moonchild said what I was thinking. His post obsoletes mine.

[smolnyn]

Moonchild said what I was thinking. His post obsoletes mine.

An exploit is able to get to the contents of the hard drive, by the method described in the article that the link points?
https://en.wikipedia.org/wiki/Blackhole_exploit_kit

If not, then the only thing that is likely for user's browser is reading the cookies, bookmarks, or, at worst, a keylogging activities?

[smolnyn]

Moonchild said what I was thinking. His post obsoletes mine.

An exploit is able to get to the contents of the hard drive, by the method described in the article that the link points?
https://en.wikipedia.org/wiki/Blackhole_exploit_kit

If not, then the only thing that is likely for user's browser is reading the cookies, bookmarks, or, at worst, a keylogging activities?

If that is so then, in my ignorance, I think that sandboxing processes follow the path of a more commercial "requirement" in the "war of the browser" rather than a real need for technical security of their personal data, ignoring the problem of navigation tracking through the scripts that did not bother me much. Eventually a Linux user can - with due caution - not worry also to use a non-up-to-date browser?

[Moonchild]

Off-topic:
"Blackhole exploit kit" is just a collective name of a number of individual exploits against older/obsolete or not updated software with known vulnerabilities.
This "kit" focuses on using those vulnerabilities to drop trojans and other malware on a user's system. Delivering this malware can be difficult, and an updated, secure browser will prevent this. Depending on the vulnerabilities exploited and the prevalence and severity of these vulnerabilities, any browser that is not current or not updated can pose a risk.
That has, however, absolutely nothing to do with this topic of multiprocess/sandboxing and is more a question of general software security.