Talk:Site isolation

Jargon
This article can greatly benefit from defining what it means by 'site', 'cross-origin site' (the latter probably should be changed to something like 'cross-origin web page', as it doesn't refer to site in the sense of origin) and 'instance' (which refers to a renderer instance like a tab or window and not a browser instance). See also https://www.chromium.org/developers/design-documents/site-isolation/ --PaulT2022 (talk) 22:54, 3 February 2024 (UTC)


 * Also, The singular rendering process would engage with other privileged services when necessary to execute elevated actions when viewing a web page. is incorrect per the Chromium link above ('Chrome made an effort to place pages from different web sites in different renderer processes when possible') and the 2013 paper referenced in the article (see table on p.80). It should be something like 'singular per rendered web page'. PaulT2022 (talk) 00:23, 4 February 2024 (UTC)
 * @PaulT2022 If you take a look at "Project progression" of the same link it mentions that the vast majority of traditional navigations (link-clicks, every other interaction) would lead to the renderer process being shared between origins. While the mechanism to seperate sites did exist, it wasn't used very much/at all, site isolation forced the architecture to be process per renderer by default.
 * Regarding the confusion wrt to 'site', the Chrom(e|ium) definition refers to eTLD+1 seperation, whereas Reis 2009 and Firefox use the complete origin as a site identifier. I do agree that the article is lacking some nuance in that aarea, and I'll see how I can add it without adding more jargon (which is hard) :) Sohom (talk) 08:26, 4 February 2024 (UTC)
 * it wasn't used very much/at all, site isolation forced the architecture to be process per renderer by default – I don't believe this was the case. Chromium used isolated renderer processes for each website from the beginning ("it swapped renderer processes for cross-site navigations that were initiated in the browser process (such as omnibox navigations or bookmarks)"). According to the 2013 paper, other browsers were too by 2013. The issue was that iframes embedded in the page were rendered by the same process, and the process was re-used when navigating to another site, which resulted in scripts potentially having access to the same memory that was used to render a page from another origin previously. PaulT2022 (talk) 14:31, 4 February 2024 (UTC)
 * @PaulT2022 I agree with what you are saying, I'm not disputing that new renderers were created for bookmark and omnibox navigations. However, that does not account for a vast majority of navigations on the web (how many times do you search a specific thing in a new tab (creates a new process) vs click on a link (reuses renderer processes)). Using the process-per-rendering-instance model for 2% of navigations and process-per-browsing-instance model for the rest, does not change the fact that the predominant model is still process-per-browsing-instance. Sohom (talk) 16:05, 4 February 2024 (UTC)
 * I agree with this (although not quantitatively with 2%, as it's a new process for each address bar navigation/search as well).
 * All I'm saying is that it isn't evident from the text, especially to someone not familiar with the background, that 'singular' means process-per-browsing-instance. PaulT2022 (talk) 16:16, 4 February 2024 (UTC)