SoylentNews is people
SoylentNews
From Firefox's faster, slicker, slimmer Quantum edition now out
[...] Collectively, the performance work being done to modernize Firefox is called Project Quantum. We took a closer look at Quantum back when Firefox 57 hit the developer channel in September, but the short version is, Mozilla is rebuilding core parts of the browser, such as how it handles CSS stylesheets, how it draws pages on-screen, and how it uses the GPU.
This work is being motivated by a few things. First, the Web has changed since many parts of Firefox were initially designed and developed; pages are more dynamic in structure and applications are richer and more graphically intensive. JavaScript is also more complex and difficult to debug. Second, computers now have many cores and simultaneous threads, giving them much greater scope to work in parallel. And security remains a pressing concern, prompting the use of new techniques to protect against exploitation. Some of the rebuilt portions are even using Mozilla's new Rust programming language, which is designed to offer improved security compared to C++.
Also at: Firefox aims to win back Chrome users with its souped up Quantum browser
The fastest version of Firefox yet is now live
(Score: 2) by TheRaven on Friday November 17 2017, @10:08AM (4 children)
I don't know how far Firefox has gone, but that's certainly not true for Chrome or Safari. The browser is split into multiple compartments, which are isolated by putting them in different processes. Network processing is isolated from the UI and each tab has a separate renderer process that receives the data for that tab, runs the scripts, and renders into a texture in shared memory. The 'browser' (parent) process transfers this texture to the screen and sends messages to the renderer process in response to user input (e.g. click here, scroll down, zoom out). The parent process has no visibility into the DOM for any page, nor access to JavaScript state. It validates URL requests, but that's about it. For security, the interface between the renderer process is as narrow as possible so that a compromise in the renderer has a narrow attack surface.
If you want to support add-ons in this model, you have to make them run either in the renderer process (in which case they can do arbitrary things to the DOM, but can't be allowed access to any global state without compromising the security model), or in the parent process (in which case they can do arbitrary things to the UI, can block network connections, but can't access the DOM). The old Firefox extension model had no separation there and most extensions used interfaces that touched both the DOM and the exterior UI (it didn't help that XUL effectively made the rest of the UI a DOM, so these APIs were the same in many cases). There is no way to make that work with a compartmentalised model.
sudo mod me up
(Score: 1, Interesting) by Anonymous Coward on Friday November 17 2017, @10:48AM (3 children)
The browser (code that you downloaded from either mozilla.org or google.com) has access to everything.
Sure it's compartmentalized, but there is still communication between compartments, otherwise the UI wouldn't work. That communication can be done for add-ons also.
Compartmentalizing these things are not to defend the page against the browser, but to prevent bugs in the parts of the browser in contact with one page to take down every page open in the browser. A good idea, especially considering the stability of browsers at the time this was introduced, but not something that add-ons should need to care about.
(Score: 2) by TheRaven on Sunday November 19 2017, @09:00PM (2 children)
sudo mod me up
(Score: 2) by FakeBeldin on Tuesday November 21 2017, @08:50AM (1 child)
Naah, GP is saying that browsers should be secure no matter what the plugins are doing.
I have no words for how wonderful an idea that is ;-)
(Score: 2) by TheRaven on Tuesday November 21 2017, @09:48AM
sudo mod me up