Re: [w3c/ServiceWorker] Support `close()` method in ServiceWorkerGlobalScope (Issue #1696)

Thanks both for sharing so much context. I honestly hadn't thought about the implications for event processing, which is clearly a major part of looking at what would be involved here.

A couple of general thoughts:

- Maybe requesting `close()` specifically implied a desire for re-using the worker implementation. I have no strong feelings there. I think this general high-level capability is interesting, but could see it making sense to have a different implementation and/or different method name.
- While I agree that we would need to specify how this impacts event processing, I think that should be a solvable problem. To some extent, this is no difference to an event arriving while the browser is trying to terminate the service worker based on a timeout, right? We could figure out the right series of locks to make sure that once a close request arrives that must finish and any subsequent events will be handled by a new service worker spun up after this one closes. I acknowledge the potential footguns/it being hard for a developer to know if an event is currently being processed though.

More specific thoughts:

> This is an important use-case, but it seems like it is better addressed by adding a [WebDriver extension command](https://w3c.github.io/webdriver/#extensions-0) which could be used by sites for testing, and then also exposed to [testdriver.js](https://web-platform-tests.org/writing-tests/testdriver.html) for use in any Web Platform Tests.

I generally agree and did mention this to them. In their case, they use WebDriver purely as a way to start the browser, and all of the test logic runs inside of the service worker (more similar to [this](https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/usb/chrome_usb_browsertest.cc;l=578;drc=155bd370301e57a0d1f55e22b7126e8cce5dbb1e) sort of thing).

> It would be good to understand how the existing functional event mechanism and the ability of content to help out garbage collection are believed to be insufficient here.

I think they are generally sufficient. Being able to terminate slightly early is nice but given the potential footguns I agree this is probably one of the weaker arguments.

> I'm unclear if there's an assumption here that freed memory will not be available to an attacker with the ability to arbitrarily read the contents of the process' address space, but it seems like https://github.com/w3c/ServiceWorker/issues/1529 could provide more confidence about this anyways.

I don't think it's possible to make a statement quite that strong. I do still see value though. In particular, if your service worker is receiving a steady stream of events, it might never die. This means that if you have a bug and are accidentally keeping a reference to some sensitive data you wanted to clear, it may stay in a state where it is very easy to access forever. Being able to call close() immediately prevents the most basic attacks (looking at the memory tab in DevTools, for example) and gives you reasonable confidence that at some point the memory will be cleared. It's by no means something to rely on, but is a good last measure of defence (as a note, I wrote the initial WECG comment when I was at 1Password, but I no longer work there and this is purely from my own POV).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1696#issuecomment-1789301051
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1696/1789301051@github.com>