Supposedly the ideal mojo situation is for a feature to use get a pipe to its browser side component via something like ExecutionContext::GetInterfaceProvider. But somehow so far none of the features I worked on (BroadcastChannel, Localstorage, Blobs) seemed to work in a way that per-frame/document mojo pipes would be possible. With Blob URLs (design) I thought I might have finally found a case where I would actually be able to use per-frame interfaces, as that would bring nice security benefits, and I do need to do certain browser-side cleanup when the frame goes away, so having a per-frame pipe seemed like it would nicely do everything I needed.But then thinking a bit more about it, I started to realize that that's just not how the web works. Basically any feature that involves any kind of state in the browser process that can be modified by the renderer will act very weirdly if requests from different frames can be arbitrarily re-ordered (as would be the case if each frame has its own mojo pipe). At best we could hope for one mojo pipe per unit of related browsing contexts, but we don't really have a way to do that currently (as far as I know). So what should we do?
--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAF3XrKpj%2BX4mwv%3DTiUJ70%3DXFB2j%3DZP7-WHtatmZOm2SFSN8qSg%40mail.gmail.com.
On Fri, Nov 17, 2017 at 4:54 PM Marijn Kruisselbrink <m...@chromium.org> wrote:Supposedly the ideal mojo situation is for a feature to use get a pipe to its browser side component via something like ExecutionContext::GetInterfaceProvider. But somehow so far none of the features I worked on (BroadcastChannel, Localstorage, Blobs) seemed to work in a way that per-frame/document mojo pipes would be possible. With Blob URLs (design) I thought I might have finally found a case where I would actually be able to use per-frame interfaces, as that would bring nice security benefits, and I do need to do certain browser-side cleanup when the frame goes away, so having a per-frame pipe seemed like it would nicely do everything I needed.But then thinking a bit more about it, I started to realize that that's just not how the web works. Basically any feature that involves any kind of state in the browser process that can be modified by the renderer will act very weirdly if requests from different frames can be arbitrarily re-ordered (as would be the case if each frame has its own mojo pipe). At best we could hope for one mojo pipe per unit of related browsing contexts, but we don't really have a way to do that currently (as far as I know). So what should we do?Not too long ago, I was thinking about proposing that all interfaces be (legacy IPC) channel-associated by default, since we've already had a number of bugs caused by reordering issues. It's a big hammer to use, but arbitrary message interleaving seems to be surprising more than helpful the majority of the time. Interfaces that wanted looser per-pipe ordering guarantees would have to opt into that behavior themselves.
DanielAs a demonstration of how this can cause problems, see the test I added in https://chromium-review.googlesource.com/c/chromium/src/+/772085 (unfortunately that tests the not-yet-specced new async cookie API, but I couldn't find another easy-to-test API that is already mojofied to demonstrate with). When set is called multiple times all from the same script I would expect the last set to always win, but with the current one-pipe-per-frame implementation that is not the case, and I fairly regularly get that test to fail with an earlier set winning out.So what should we do?Marijn (who will be OOO next week, so I might not reply to any responses in a very timely manner...)
--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.
To post to this group, send email to chromi...@chromium.org.
Or possibly site-associated interfaces? :pOn Sat, Nov 18, 2017 at 11:04 PM, Ken Rockot <roc...@chromium.org> wrote:As for the question of ordering assumptions at the frame API layer specifically (i.e. the mek's concerns), that sounds like we're maybe missing an abstraction for interface ownership that sort of represents "render process" but is actually somewhere between that and individual frames. I don't know if the platform defines a term for it, but I think it's essentially a closed set of mutually scriptable frames. Is that a "site instance"? Do we need site instance scoped interfaces?
On Sat, Nov 18, 2017 at 10:59 PM, Ken Rockot <roc...@chromium.org> wrote:On Sat, Nov 18, 2017 at 12:21 PM, Daniel Cheng <dch...@chromium.org> wrote:On Fri, Nov 17, 2017 at 4:54 PM Marijn Kruisselbrink <m...@chromium.org> wrote:Supposedly the ideal mojo situation is for a feature to use get a pipe to its browser side component via something like ExecutionContext::GetInterfaceProvider. But somehow so far none of the features I worked on (BroadcastChannel, Localstorage, Blobs) seemed to work in a way that per-frame/document mojo pipes would be possible. With Blob URLs (design) I thought I might have finally found a case where I would actually be able to use per-frame interfaces, as that would bring nice security benefits, and I do need to do certain browser-side cleanup when the frame goes away, so having a per-frame pipe seemed like it would nicely do everything I needed.But then thinking a bit more about it, I started to realize that that's just not how the web works. Basically any feature that involves any kind of state in the browser process that can be modified by the renderer will act very weirdly if requests from different frames can be arbitrarily re-ordered (as would be the case if each frame has its own mojo pipe). At best we could hope for one mojo pipe per unit of related browsing contexts, but we don't really have a way to do that currently (as far as I know). So what should we do?Not too long ago, I was thinking about proposing that all interfaces be (legacy IPC) channel-associated by default, since we've already had a number of bugs caused by reordering issues. It's a big hammer to use, but arbitrary message interleaving seems to be surprising more than helpful the majority of the time. Interfaces that wanted looser per-pipe ordering guarantees would have to opt into that behavior themselves.It's already an explicit decision you have to make when adding a frame/host interface. I'm not sure what you mean by "by default" unless you're referring to our recommendation of what choice a developer should make.I still believe it's not an acceptable long-term solution to lean on the legacy IPC channel for global event ordering across arbitrary and otherwise independent features. Maybe it does make sense to keep certain interfaces ordered indefinitely, but we should take a more thoughtful approach to it and be able to justify the ordering with meaningful abstractions at the interface layer.
For example, you could imagine we define a (total strawman) FrameControl interface, and add a generic sort of GetControlAssociatedInterface(associated GenericInterface&) method, like we do for IPC Channel now. Then we could build up rational API surface around associating feature-specific frame/host interfaces with frame control events. In order to understand what that really looks like though, we need to understand exactly what we're modeling and why the ordering dependencies are necessary. And of course if they're not necessary, we should instead strive to eliminate them.
DanielAs a demonstration of how this can cause problems, see the test I added in https://chromium-review.googlesource.com/c/chromium/src/+/772085 (unfortunately that tests the not-yet-specced new async cookie API, but I couldn't find another easy-to-test API that is already mojofied to demonstrate with). When set is called multiple times all from the same script I would expect the last set to always win, but with the current one-pipe-per-frame implementation that is not the case, and I fairly regularly get that test to fail with an earlier set winning out.So what should we do?Marijn (who will be OOO next week, so I might not reply to any responses in a very timely manner...)
--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To post to this group, send email to chromi...@chromium.org.
On Sat, Nov 18, 2017 at 4:05 AM Ken Rockot <roc...@chromium.org> wrote:Or possibly site-associated interfaces? :pOn Sat, Nov 18, 2017 at 11:04 PM, Ken Rockot <roc...@chromium.org> wrote:As for the question of ordering assumptions at the frame API layer specifically (i.e. the mek's concerns), that sounds like we're maybe missing an abstraction for interface ownership that sort of represents "render process" but is actually somewhere between that and individual frames. I don't know if the platform defines a term for it, but I think it's essentially a closed set of mutually scriptable frames. Is that a "site instance"? Do we need site instance scoped interfaces?"Site instance" is the term Chrome uses (note that the spec calls it a unit of related similar-origin browsing contexts). I don't think we'd want per-site-instance interfaces: the unit of granularity for interfaces should still be per-frame (a site instance can't have a precise origin associated with it, since it contains 'similar-origin' contexts). But I can imagine a solution where frames in the same site-instance all share this message pipe. Would it be more acceptable to have the 'default' registry for a frame be associated with a per-site-instance message pipe?
On Sat, Nov 18, 2017 at 10:59 PM, Ken Rockot <roc...@chromium.org> wrote:On Sat, Nov 18, 2017 at 12:21 PM, Daniel Cheng <dch...@chromium.org> wrote:On Fri, Nov 17, 2017 at 4:54 PM Marijn Kruisselbrink <m...@chromium.org> wrote:Supposedly the ideal mojo situation is for a feature to use get a pipe to its browser side component via something like ExecutionContext::GetInterfaceProvider. But somehow so far none of the features I worked on (BroadcastChannel, Localstorage, Blobs) seemed to work in a way that per-frame/document mojo pipes would be possible. With Blob URLs (design) I thought I might have finally found a case where I would actually be able to use per-frame interfaces, as that would bring nice security benefits, and I do need to do certain browser-side cleanup when the frame goes away, so having a per-frame pipe seemed like it would nicely do everything I needed.But then thinking a bit more about it, I started to realize that that's just not how the web works. Basically any feature that involves any kind of state in the browser process that can be modified by the renderer will act very weirdly if requests from different frames can be arbitrarily re-ordered (as would be the case if each frame has its own mojo pipe). At best we could hope for one mojo pipe per unit of related browsing contexts, but we don't really have a way to do that currently (as far as I know). So what should we do?Not too long ago, I was thinking about proposing that all interfaces be (legacy IPC) channel-associated by default, since we've already had a number of bugs caused by reordering issues. It's a big hammer to use, but arbitrary message interleaving seems to be surprising more than helpful the majority of the time. Interfaces that wanted looser per-pipe ordering guarantees would have to opt into that behavior themselves.It's already an explicit decision you have to make when adding a frame/host interface. I'm not sure what you mean by "by default" unless you're referring to our recommendation of what choice a developer should make.I still believe it's not an acceptable long-term solution to lean on the legacy IPC channel for global event ordering across arbitrary and otherwise independent features. Maybe it does make sense to keep certain interfaces ordered indefinitely, but we should take a more thoughtful approach to it and be able to justify the ordering with meaningful abstractions at the interface layer.This aspect of Mojo differs considerably from the typical expectations around sequencing in C++. It's natural to expect that given:object1->Update();object2->Update();Update() will be invoked on |object1| before |object2|. But if |object1| and |object2| are actually Mojo interface proxies, and they don't share a message pipe (the default common case), then there is no such guarantee. In addition, Mojo method calls look exactly like method calls, so it's easy to miss this fact. The results are often surprising in subtle ways (read: security and functionality bugs).
Daniel
For example, you could imagine we define a (total strawman) FrameControl interface, and add a generic sort of GetControlAssociatedInterface(associated GenericInterface&) method, like we do for IPC Channel now. Then we could build up rational API surface around associating feature-specific frame/host interfaces with frame control events. In order to understand what that really looks like though, we need to understand exactly what we're modeling and why the ordering dependencies are necessary. And of course if they're not necessary, we should instead strive to eliminate them.
DanielAs a demonstration of how this can cause problems, see the test I added in https://chromium-review.googlesource.com/c/chromium/src/+/772085 (unfortunately that tests the not-yet-specced new async cookie API, but I couldn't find another easy-to-test API that is already mojofied to demonstrate with). When set is called multiple times all from the same script I would expect the last set to always win, but with the current one-pipe-per-frame implementation that is not the case, and I fairly regularly get that test to fail with an earlier set winning out.So what should we do?Marijn (who will be OOO next week, so I might not reply to any responses in a very timely manner...)
--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAF3XrKpj%2BX4mwv%3DTiUJ70%3DXFB2j%3DZP7-WHtatmZOm2SFSN8qSg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAF3XrKqXuipSRL0n%3DPwmJPeDeB8Po1ri%3DVvJdvQB%2BWmezvES6g%40mail.gmail.com.
This aspect of Mojo differs considerably from the typical expectations around sequencing in C++. It's natural to expect that given:object1->Update();object2->Update();Update() will be invoked on |object1| before |object2|. But if |object1| and |object2| are actually Mojo interface proxies, and they don't share a message pipe (the default common case), then there is no such guarantee. In addition, Mojo method calls look exactly like method calls, so it's easy to miss this fact. The results are often surprising in subtle ways (read: security and functionality bugs).I think we need to find a way to cope with this without giving up and throwing everything into a single pipe.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CA%2BapAgFnguziEzrr9UB5u%3DnX6o6XfCDO%2BGD0B6e8TDMfSLiZNQ%40mail.gmail.com.
Daniel
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAF3XrKpj%2BX4mwv%3DTiUJ70%3DXFB2j%3DZP7-WHtatmZOm2SFSN8qSg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAF3XrKqXuipSRL0n%3DPwmJPeDeB8Po1ri%3DVvJdvQB%2BWmezvES6g%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CA%2BapAgFnguziEzrr9UB5u%3DnX6o6XfCDO%2BGD0B6e8TDMfSLiZNQ%40mail.gmail.com.
--Kentaro Hara, Tokyo, Japan
--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jybaf2U9TZbGCNTfwpYaPvtR8MpFh_5TdN7rN23k8C2Sw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAMGE5NH7ZvjsoBJ%3DZX-AiVOey-uSWUmbNY8v%3DWonK_8LuF%3Dwyw%40mail.gmail.com.
I'm still on the fence about this. While these examples are compelling, I'm not convinced that all the use cases presented have the same requirements. LocalStorage seems to want one connection per origin. BroadcastChannel seems to need one per group of related same-origin contexts. Cookies (assuming you want them to be ordered across synchronously-scriptable contexts with document.domain set) would need to be per-site-instance.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAJqEsoCj-TKZgGS%3D_jHJFEL8idmz1s-hvhQmzPP5-xurw_aeSg%40mail.gmail.com.
On Tue, Nov 21, 2017 at 4:04 AM 'Sam McNally' via platform-architecture-dev <platform-arc...@chromium.org> wrote:I'm still on the fence about this. While these examples are compelling, I'm not convinced that all the use cases presented have the same requirements. LocalStorage seems to want one connection per origin. BroadcastChannel seems to need one per group of related same-origin contexts. Cookies (assuming you want them to be ordered across synchronously-scriptable contexts with document.domain set) would need to be per-site-instance.Can you elaborate on the distinction that you're drawing between these latter two?
On Tue, 21 Nov 2017 at 23:25 Colin Blundell <blun...@chromium.org> wrote:On Tue, Nov 21, 2017 at 4:04 AM 'Sam McNally' via platform-architecture-dev <platform-arc...@chromium.org> wrote:I'm still on the fence about this. While these examples are compelling, I'm not convinced that all the use cases presented have the same requirements. LocalStorage seems to want one connection per origin. BroadcastChannel seems to need one per group of related same-origin contexts. Cookies (assuming you want them to be ordered across synchronously-scriptable contexts with document.domain set) would need to be per-site-instance.Can you elaborate on the distinction that you're drawing between these latter two?Related same-origin contexts are just those with the same origin that can synchronously script each other; e.g. if foo.example.com contains iframes from foo.example.com and bar.example.com, then both foo.example.com frames are in the same group of related same-origin contexts, since they can synchronously script each other and are same-origin, but bar.example.com is not.In the case of related similar-origin contexts, bar.example.com would be part of the group since if all frames set document.domain to example.com, they can synchronously script each other. This is what SiteInstance models.BroadcastChannel, like most web APIs, is origin-scoped; in a similar test where messages were broadcast from each frame synchronously, only the order of the two foo.example.com messages matters; each receiver would either receive only the foo.example.com messages or only the bar.example.com message. Thus, related same-origin contexts would need to share a connection (either directly or via associated interfaces).Cookies have their own scoping restrictions: foo.example.com and bar.example.com can both set cookies for example.com. Thus, for the same example setup with document.domain set, the order between the set cookie message from foo.example.com and bar.example.com is observable. Thus, if consistent ordering is required for cookies, related similar-origin contexts would need to share a connection.
On Wed, Nov 22, 2017 at 10:38 AM Sam McNally <sa...@google.com> wrote:
On Tue, 21 Nov 2017 at 23:25 Colin Blundell <blun...@chromium.org> wrote:
Daniel
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAF3XrKpj%2BX4mwv%3DTiUJ70%3DXFB2j%3DZP7-WHtatmZOm2SFSN8qSg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAF3XrKqXuipSRL0n%3DPwmJPeDeB8Po1ri%3DVvJdvQB%2BWmezvES6g%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CA%2BapAgFnguziEzrr9UB5u%3DnX6o6XfCDO%2BGD0B6e8TDMfSLiZNQ%40mail.gmail.com.
--Kentaro Hara, Tokyo, Japan--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jybaf2U9TZbGCNTfwpYaPvtR8MpFh_5TdN7rN23k8C2Sw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.
To post to this group, send email to chromi...@chromium.org.
--To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAMGE5NH7ZvjsoBJ%3DZX-AiVOey-uSWUmbNY8v%3DWonK_8LuF%3Dwyw%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architecture-dev+unsub...@chromium.org.
To post to this group, send email to platform-architecture-dev@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAJqEsoCj-TKZgGS%3D_jHJFEL8idmz1s-hvhQmzPP5-xurw_aeSg%40mail.gmail.com.
Two questions:- Is there any difference between "related same-origin contexts" (in the spec term) and "site" (in the Chrome term)?
- What's a downside of making message pipes per-site by default? In terms of correctness, it will be fine (or too much for some use cases). In terms of performance, is there any downside?
Daniel
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAF3XrKpj%2BX4mwv%3DTiUJ70%3DXFB2j%3DZP7-WHtatmZOm2SFSN8qSg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAF3XrKqXuipSRL0n%3DPwmJPeDeB8Po1ri%3DVvJdvQB%2BWmezvES6g%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CA%2BapAgFnguziEzrr9UB5u%3DnX6o6XfCDO%2BGD0B6e8TDMfSLiZNQ%40mail.gmail.com.
--Kentaro Hara, Tokyo, Japan--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CABg10jybaf2U9TZbGCNTfwpYaPvtR8MpFh_5TdN7rN23k8C2Sw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.
To post to this group, send email to chromi...@chromium.org.
--To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAMGE5NH7ZvjsoBJ%3DZX-AiVOey-uSWUmbNY8v%3DWonK_8LuF%3Dwyw%40mail.gmail.com.
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To post to this group, send email to platform-arc...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAJqEsoCj-TKZgGS%3D_jHJFEL8idmz1s-hvhQmzPP5-xurw_aeSg%40mail.gmail.com.
On Wed, Nov 22, 2017 at 6:00 PM Kentaro Hara <har...@google.com> wrote:Two questions:- Is there any difference between "related same-origin contexts" (in the spec term) and "site" (in the Chrome term)?A site is eTLD + 1. So if the origin is drive.google.com, the site is google.com. It is essentially the most coarse origin that document.domain could downgrade to.A site instance corresponds to a collection of related *similar* origin contexts. Two pages are similar origin if they can use document.domain to be come same origin. These pages must always be kept in the same process so that they can synchronously script each other if document.domain allows it.(Note there are probably a few subtleties of site instance that lead it to not a 1:1 correspondence of the spec term, but it's pretty close)- What's a downside of making message pipes per-site by default? In terms of correctness, it will be fine (or too much for some use cases). In terms of performance, is there any downside?It only works if all the interfaces have same host process. So if we have a network service, that stuff wouldn't be associated with things homed in the browser process.