Ordering issues with per-frame/document mojo pipes

[Marijn Kruisselbrink]

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?

As 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...)

[Daniel Cheng]

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.

Daniel

[Kentaro Hara]

+Sam +Ken

I think Sam and Ken have some plan to expose channel-associated interfaces to Blink to cover these use cases...?

Also we've already exposed an associated interface to Blink. If an associated interface is sufficient for your use case, you can use it.

--
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.

--

Kentaro Hara, Tokyo, Japan

[Marijn Kruisselbrink]

Yeah, there is definitely ways to make it work. But I'd argue that we're in a very dangerous situation where the default choice (i.e. ExecutionContext::GetInterfaceProvider()) is the wrong choice in many cases, and you are made to argue your case (with platform OWNERS in the one you link to, although I've had similar discussion with security folk about why I'm not using a per-frame pipe) to do the correct thing. Not sure what the right answer is, but the current situation at least makes me feel like the only way to implement features correctly is by doing things I'm not supposed to be doing (there have been several threads with various groups of people about why the features I've been working on aren't using per-frame pipes...)

[Ken Rockot]

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.

 

Daniel

 

As 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.

[Ken Rockot]

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?

[Ken Rockot]

Or possibly site-associated interfaces? :p

[Daniel Cheng]

On Sat, Nov 18, 2017 at 4:05 AM Ken Rockot <roc...@chromium.org> wrote:

Or possibly site-associated interfaces? :p

On 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.

Daniel

 

As 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.

[Ken Rockot]

On Nov 18, 2017 6:51 AM, "Daniel Cheng" <dch...@chromium.org> wrote:

On Sat, Nov 18, 2017 at 4:05 AM Ken Rockot <roc...@chromium.org> wrote:

Or possibly site-associated interfaces? :p

On 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? 

Yeah, a per-site master interface might make sense for frame interface association. I am optimistic that we could rationalize a good API around that concept.

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).

I think we need to find a way to cope with this without giving up and throwing everything into a single pipe.

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.

Daniel

 

As 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 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/CAF3XrKqXuipSRL0n%3DPwmJPeDeB8Po1ri%3DVvJdvQB%2BWmezvES6g%40mail.gmail.com.

[Kentaro Hara]

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.

IIUC the proposal of Daniel and Marjin is just to make the message pipe per-site rather than per-frame. Wouldn't it be kind of acceptable? The proposal is not to create a single pipe.

FWIW this discussion on scheduler-dev is somewhat related and interesting. tzik@ proposed making Blink's task scheduling per-site (according to the current spec; because the per-frame scheduling may cause the ordering issues we're discussing here) but the scheduler team wants to keep the per-frame scheduling and change the spec accordingly (to get more flexibility on task scheduling).

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.

[Colin Blundell]

My two cents:

- I agree with Ken that we should focus on finding the "concrete abstractions" (so to speak) that make sense in terms of where ordering is required.

- From my somewhat layman's perspective and reading of this thread, per-site-instance does seem like that abstraction in this case.

Best,

Colin

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 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/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.

[Sam McNally]

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. I think we need to clarify these requirements before adding new connection types.

On the cookies example, https://github.com/WICG/cookie-store/blob/gh-pages/explainer.md#api-forwarding-non-goal suggests that a value set last from any of the frames should be a valid result.

For blobs, I think that proposal is mostly workable as is. As long as the loading code can deal with blobs (either directly or via something else holding the blob handle) instead of only URLs (and according to the URL spec it probably should), making Resolve and Revoke sync as well seems like it should work. If the cross-context revoke can be dropped, then each renderer could also keep a record of all the blob URLs it owns for blob URL resolution (with tombstones for revocation) and revoke wouldn't need to be sync.

Lastly, associating an interface with any interface that's going to be implemented by the network service is not going to work when the network service runs out of process.

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.

[Colin Blundell]

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?

 

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.

[Sam McNally]

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.

[Colin Blundell]

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:

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.

This all makes sense, thanks! A followup question then: What is the distinction that you're drawing between LocalStorage and BroadcastChannel in your first mail above?

[Kentaro Hara]

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?

On Wed, Nov 22, 2017 at 7:54 PM, Colin Blundell <blun...@chromium.org> wrote:

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 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/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.

[Daniel Cheng]

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.

(I'm not sure if it'd be possible to use per-site pipes to services that don't live in in browser)

Daniel

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 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/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.

[Colin Blundell]

On Thu, Nov 23, 2017 at 3:44 AM Daniel Cheng <dch...@chromium.org> wrote:

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.

If we need ordering between messages sent to interfaces in two different services, it seems like we'd need to have one service intermediate the connection to the other. So e.g. Blink would connect to the browser service, which would forward the relevant requests onto the network service and handle any ordering requirements with other stuff located in the browser service.