So, most plugins need to access the filesystem and the network, which makes them a security concern. In fact, the reason plugins were adopted is because they provide access to resources the browser does not typically provide, such as video rendering or access to the webcam or raw network access. Traditionally, browser plugins were not restricted to what they can access on a computer. They may only talk to the browser process to request resources (images, html etc). In addition, one can use this to enhance a browser's security by asking the operating systems to restrict a process' access to the machine's resources.įor example, the tab renderer processes are not allowed to read or write to the disk or network of the computer. The immediate impact is that a crash or a slowdown in the renderer does not slow down the other renderers, or the main browser. 1 for the browser, 1 for Flash, and 1 per tab. Bugs and crashes in one process do not (usually) affect other processes.Ĭhrome uses multiple process: One for the browser (networking, cache, cookies, bookmarks, sync, among others), one per website renderer (HTML, JS, CSS parsing, javascript execution, actual rendering of the page in the screen), and one per plug-in such as Java and Flash. On Windows, hitting Ctrl-Alt-Delete lists (some of) the running processes of the system at any time, and lets you 'kill' a process that you think is misbehaving. A process has its own piece of memory, and is a concept quite familiar even to end users. One of the basic concepts that the operating system provides is that of a process. It's currently on the dev-channel of Chrome, which is an unstable build targeted at users who like to browse on the edge. On Dec 1, 2010, Google developers Justin Schuh and Carlos Pizano announced the release of the first iteration of the security sandbox for the Adobe Flash plugin in Google Chrome (for Windows).

Google chrome for mac os x 10.5.8