640GB should be enough for anybody —

Chrome 63 offers even more protection from malicious sites, using even more memory

Google gives Administrators new ways to lock down the browser.

You might need more of this stuff if you want to use Chrome's new Site Isolation mode. Well, not this stuff exactly; it's RAM from a very obsolete VAX computer.
Enlarge / You might need more of this stuff if you want to use Chrome's new Site Isolation mode. Well, not this stuff exactly; it's RAM from a very obsolete VAX computer.

To further increase its enterprise appeal, Chrome 63—which hit the browser's stable release channel yesterday—includes a couple of new security enhancements aimed particularly at the corporate market.

The first of these is site isolation, an even stricter version of the multiple process model that Chrome has used since its introduction. Chrome uses multiple processes for several security and stability reasons. On the stability front, the model means that even if a single tab crashes, other tabs (and the browser itself) are unaffected. On the security front, the use of multiple processes makes it much harder for malicious code from one site to steal secrets (such as passwords typed into forms) of another.

Chrome's default model is, approximately, to use one process per tab. This more or less ensures that unrelated sites are kept in separate processes, but there are nuances to this set-up. Pages share a process if they are related through, for example, one opening another with JavaScript or iframes embedding (wherein one page is included as content within another page). Over the course of a single browsing session, one tab may be used to visit multiple different domains; they'll all potentially be opened within a single process. On top of this, if there are already too many Chrome processes running, Chrome will start opening new pages within existing processes, resulting in even unrelated pages sharing a process.

Chrome 63 introduces a new mode called "Site Isolation." In Site Isolation mode, this sharing is eliminated and the browser applies a much stricter policy to ensure that individual sites remain in separate processes. Even pages that were formerly "related" (and hence eligible for a shared process) will be separated, and a long browsing session within a tab that spans several different sites will get a new process each time a new domain is visited. The process sharing due to having a large number of processes is also disabled with this mode.

Google has had to update Chrome to enable this mode. One of the reasons that sharing was used initially is that some pages are allowed to communicate with one another, using certain JavaScript mechanisms. Originally, these mechanisms only worked when the different pages used the same process. In Chrome 63, that communication can cross between processes. Similarly, embedded iframes can use a different process for the parent than for the child.

Naturally, this greater use of multiple processes incurs a price; with this option enabled, Chrome's already high memory usage can go up by another 10 to 20 percent. As such, it's not enabled by default; instead, it's intended for use by enterprise users that are particularly concerned about organizational security.

The different blockable extension permissions.
Enlarge / The different blockable extension permissions.

The other new capability is the ability for administrators to block extensions depending on the features those extensions need to use. For example, an admin can block any extension that tries to use file system access, that reads or writes the clipboard, or that accesses the webcam or microphone.

Additionally, Google has started to deploy TLS 1.3, the latest version of Transport Layer Security, the protocol that enables secure communication between a browser and a Web server. In Chrome 63, this is only enabled between Chrome and Gmail; in 2018, it'll be turned on more widely.

Reader Comments (95)

View comments on forum

Loading comments...

Channel Ars Technica