Cookies missing on very first request if website has service worker with fetch event handler

[steffenweber]

Description

If a website has a service worker with a non-trivial "fetch" event handler (i.e. it doesn't just do nothing but uses the Fetch API to return a response) then the very first request to a website is sent without any cookies. (For more details on service workers in general see the MDN docs Using Service Workers.)

This is the very same issue that I reported to uMatrix yesterday. You might want to have a look at their fix: uBlockOrigin/uMatrix-issues#155

Steps to Reproduce

1. Open https://www.computerbase.de/ to initialize the service worker and to get a "service-worker-init-date" cookie (any cookie would do)
2. In the same tab, open any other website, for example https://www.google.com/
3. In the same tab, open https://www.computerbase.de/ again

Expected Behavior

The GET request for https://www.computerbase.de/ should have the "service-worker-init-date" cookie set.

Actual Behavior

The GET request for https://www.computerbase.de/ is sent without any cookies (as can be seen in the "Network" tab of the Firefox developer tools).

Notes

If you now click on any local link (or reload the page) then the cookies are sent. It's just the very first request that is sent without cookies.

The issue goes away if I either uninstall/disable Ghostery or if I delete the "fetch" event handler from the computerbase.de service worker (I'm the admin of computerbase.de). It seems like the very first request is somehow treated in a special way and gets stripped of all cookies by Ghostery.

This issue affects the login cookies of computerbase.de and was reported to me in our feedback forum by one of our users (nickname "Cave Johnson"): https://www.computerbase.de/forum/threads/login-probleme-seit-14-mai-der-aktive-benutzer-hat-sich-geaendert.1872153/

Versions

• Browser: Chrome 74 and Firefox 68
• OS: Windows, Linux (and probably Mac, too)

[sammacbeth]

Hi @steffenweber, thanks for reporting this.

This is an issue with the way we determine the origin of a tab. Previously we could assume that there was a main_frame request for each page loaded, which we could use as the tab's origin until the next main_frame request. However, service-workers have broken this assumption, as when a page's document is served from the service-worker, there is no main_frame request observed by the extension.

I've created a fix to detect this case, and we'll try and get it in the next release.

[ghostwords]

If this is what I think it is, these are browser bugs.

• Chrome/Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=946908
• Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1499523

[ghostwords]

@sammacbeth Where can I see your workaround?

[sammacbeth]

@ghostwords Yes, these bugs are exactly this issue, thanks for the links.

The fix is currently in the upstream browser-core project, and at internal review at the moment.

Here's the method I used:

• Listen to chrome.webNavigation.{onBeforeNavigate,onCommitted} events.
• When onBeforeNavigate fires for a tab, flag the tab as 'navigating'
• If a webRequest occurs of type beacon, it belongs to the previous page in that tab.
• If a webRequest occurs of type main_frame, remove the 'navigating' flag from the tab.
• If a webRequest occurs of type xmlhttprequest, it's from the service worker (on Firefox the documentUrl property points to the service worker). Create a fake main_frame request from the originUrl (Firefox) or initiator (Chrome). Remove the 'navigating' flag from the tab.
• If onCommitted fires and the tab still has the 'navigating' flag, create a fake main_frame using the tab url.

[ghostwords]

Thanks! Will you link to the public PR once it becomes available?