In general, same origin frames must be in the same process, as they have synchronous scripting access to each other. Same is true for windows created through window.open(), if they are same origin, they must stay in the same process. So I'm not sure why there are security/privacy concerns.

If the frames were cross-origin and we leaked whether they are in the same process or not, then I can see concerns, but it doesn't seem this is the case described.

> In general, same origin frames must be in the same process, as they have synchronous scripting access to each other.

Ah okay, then there are exactly 0 bits of information leaked. Thanks. :)

Although just to clarify:
"""
same origin frames must be in the same process,
"""

If I open multiple tabs to google.com, they are not hosted in the same process.

If you open multiple tabs, they may or may not be in same process, depending on how many processes are already in use. Again, what is the privacy/security implication of knowing whether another tab exists that is in the same process? 

Additionally, my understanding is that we are going to update performance.memory to explicitly return null if there is more than one tab in the same process, so that will be an immediate info leak that some other tab runs alongside your document. So if there are privacy implications, then this change is much more direct leak than any cookies/localStorage mechanism.

> If you open multiple tabs, they may or may not be in same process, depending on how many processes are already in use.

The statement is that any frame can get the URLs of other same origin frames being hosted in the same process, assuming those other frames are actively participating, by using the process memory stats as a rough identifier.

> Again, what is the privacy/security implication of knowing whether another tab exists that is in the same process? 

I can't think of any immediate privacy/security concerns, but others may think of something, which is why the opening comment has:

"""
We don't think there are any privacy/security concerns, but filing the bug just in case.
"""

Apologies if my last update came across negatively, it was not my intention and I'm genuinely interested in understanding what are the implications of knowledge of process sharing.

Just to chime in with a few more concrete details, same-origin frames will be in the same process if they're in the same BrowsingInstance (i.e., group of related tabs/frames with references to each other), and will usually be in different processes if they are in separate BrowsingInstances, unless we're over the process limit and start sharing.  There's a few other exceptions as well, such as OOPIFs proactively joining an existing process, and Alex's upcoming CL to swap BrowsingInstances on cross-site omnibox navigations (etc).

Thus, this signal would mostly be influenced by how the user chose to get to these pages.  Thus, if there's any privacy implications, it's around detecting whether the user got to same-origin pages via links or by opening a new tab from scratch, which doesn't seem very concerning from my perspective.  There's also so many corner cases that it would make the data hard to interpret anyway, and there may be better ways to determine that anyway (e.g., referrer).

I don't see any security risks here.  I'll let Jochen comment on privacy, but I wouldn't expect it to be a concern there either.

+vogelheim@ who reviewed the API change from privacy perspective.

I have a hard time finding a way to exploit this information. In any case, performance.memory is much saner from privacy perspective in the site isolation world than it was before.