Service worker support in SXG

[Ulan Degenbaev]

Hi folks,

I have a use case for distributing the service worker source script via SXG:

navigator.serviceWorker.register('https://distributor.com/service_worker.sxg');

I found two service-worker related issues: crbug.com/898733, crbug.com/939237 but they seem abandoned. 

I have two questions:

- Are you planning to support service workers in SXG at some point in future?

- Do you see any fundamental blockers for the use case I mentioned?

Thanks,

Ulan.

[Kenji Baheux]

Hi Ulan,

I'm curious to hear details about your use case.

What problem are you trying to solve with this approach? 

--
You received this message because you are subscribed to the Google Groups "WebPackage-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webpackage-de...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/webpackage-dev/b16f356d-fefb-44b4-b007-bae388766138n%40chromium.org.

[Ulan Degenbaev]

Hi Kenji,

We have a set of untrusted "front-end" servers that may potentially be compromised and/or malicious. We would like to distribute the service worker and the main website of the trusted domain using SXG.

In other words, the use case is very similar to the original motivation for SXG except that it also includes the service worker.

Do you know if the missing support for the service worker is a matter incomplete implementation or does the spec explicitly disallow service workers due to some fundamental blockers?

Thanks,

Ulan.

[Kenji Baheux]

On Sun, Dec 18, 2022 at 11:40 PM Ulan Degenbaev <udege...@gmail.com> wrote:

Hi Kenji,

We have a set of untrusted "front-end" servers that may potentially be compromised and/or malicious. We would like to distribute the service worker and the main website of the trusted domain using SXG.

The scenario isn't super clear to me.

For instance, if one of the front-end servers is compromised, what's preventing the bad actor from using this compromised front-end server to send a modified main document with a SW registration pointing to a same-origin script that might also have been modified?

Could you provide more details about the setup, the different parties involved, and the attack you are trying to mitigate / prevent?

 

In other words, the use case is very similar to the original motivation for SXG except that it also includes the service worker.

Do you know if the missing support for the service worker is a matter incomplete implementation or does the spec explicitly disallow service workers due to some fundamental blockers?

The script for SW registration has a same-origin restriction.

I imagine that the spec could allow SXG if they can be proven to be originally from the same-origin of the main doc.

This should be possible to be implemented as well.

It really depends on what problem this is solving, the existence of alternatives, and how important / costly fixing this problem is versus others that the team could work on.

 

Thanks,

Ulan.

On Thursday, December 15, 2022 at 4:07:16 AM UTC+1 Kenji Baheux wrote:

Hi Ulan,

I'm curious to hear details about your use case.

What problem are you trying to solve with this approach? 

On Wed, Dec 14, 2022 at 10:40 PM Ulan Degenbaev <udege...@gmail.com> wrote:

Hi folks,

I have a use case for distributing the service worker source script via SXG:

navigator.serviceWorker.register('https://distributor.com/service_worker.sxg');

I found two service-worker related issues: crbug.com/898733, crbug.com/939237 but they seem abandoned. 

I have two questions:

- Are you planning to support service workers in SXG at some point in future?

- Do you see any fundamental blockers for the use case I mentioned?

Thanks,

Ulan.

--
You received this message because you are subscribed to the Google Groups "WebPackage-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webpackage-de...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/webpackage-dev/b16f356d-fefb-44b4-b007-bae388766138n%40chromium.org.

--
You received this message because you are subscribed to the Google Groups "WebPackage-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to webpackage-de...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/webpackage-dev/a8b13f65-87f2-4616-8f87-cca2e622cf6dn%40chromium.org.

[Ulan Degenbaev]

> For instance, if one of the front-end servers is compromised, what's preventing the bad actor from using this compromised front-end server to send a modified main document with a SW registration pointing to a same-origin script that might also have been modified?

> Could you provide more details about the setup, the different parties involved, and the attack you are trying to mitigate / prevent?

The front-end server has a different origin. In other words, it is like a CDN server. To be concrete, let's say we have `https://trusted.com` as the main origin and `https://untrusted.com` as the front-end server. We would like to host the main page and the service worker of `https://trusted.com` as SXG resources on `https://untrusted.com`.

So there would be `https://untrusted.com/trusted-main-html.sxg` that corresponds to the main trusted page and registers a service worker like `navigator.serviceWorker.register('https://untrusted.com/service-worker.sxg');`

> The script for SW registration has a same-origin restriction.

> I imagine that the spec could allow SXG if they can be proven to be originally from the same-origin of the main doc.

Yes, that is my understanding as well. In the example the browser can verify that `service-worker.sxg` corresponds `https://trusted.com` by checking the signatures, so the same-origin restriction is respected.

> This should be possible to be implemented as well.

> It really depends on what problem this is solving, the existence of alternatives, and how important / costly fixing this problem is versus others that the team could work on.

Got it, thanks! Did I understand correctly, that there are no fundamental blockers besides potential lack of engineering resources?

[Kenji Baheux]

On Fri, Jan 13, 2023 at 12:29 AM Ulan Degenbaev <udege...@gmail.com> wrote:

> For instance, if one of the front-end servers is compromised, what's preventing the bad actor from using this compromised front-end server to send a modified main document with a SW registration pointing to a same-origin script that might also have been modified?

> Could you provide more details about the setup, the different parties involved, and the attack you are trying to mitigate / prevent?

The front-end server has a different origin. In other words, it is like a CDN server. To be concrete, let's say we have `https://trusted.com` as the main origin and `https://untrusted.com` as the front-end server. We would like to host the main page and the service worker of `https://trusted.com` as SXG resources on `https://untrusted.com`.

So there would be `https://untrusted.com/trusted-main-html.sxg` that corresponds to the main trusted page and registers a service worker like `navigator.serviceWorker.register('https://untrusted.com/service-worker.sxg');`

Thanks for the extra details.

 

> The script for SW registration has a same-origin restriction.

> I imagine that the spec could allow SXG if they can be proven to be originally from the same-origin of the main doc.

Yes, that is my understanding as well. In the example the browser can verify that `service-worker.sxg` corresponds `https://trusted.com` by checking the signatures, so the same-origin restriction is respected.

> This should be possible to be implemented as well.

> It really depends on what problem this is solving, the existence of alternatives, and how important / costly fixing this problem is versus others that the team could work on.

Got it, thanks! Did I understand correctly, that there are no fundamental blockers besides potential lack of engineering resources?

Re no fundamental blockers, that's my guess but I'm not 100% sure.

If you want to confirm, you may want to file an issue on the github repo for the ServiceWorker spec.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/webpackage-dev/1ec6d266-30eb-4d3d-96f0-e5aa31ed58e4n%40chromium.org.