How are ServiceWorkers and ServiceWorkerContainer.prototype.register, used for fingerprinting and bot detection

Viewed 195

I often see websites that have advanced bot detection/fingerprinting technology that make use of ServiceWorkers and/or ServiceWorkerContainer.prototype.register. I'm not sure what exactly they do with it. There is also a chrome extension, Dont FingerPrint Me, that claims ServiceWorkers are used for fingerprinting and provides a feature to detect when a website does so. However, it doesn't explain how they are used. I've tried understanding it by reading the code, but did not get anywhere.

So, my question is, how can that be used for fingerprinting or detecting bots? By bots I mean browsers automated via selenium, remote debugger, or some other automation tool.

Edit: Unfortunately, atm I don't have any links saved of some sites I've previously come across that are using this technology. If I find one again I will update the post.

Edit: I was told that they can be used to bypass fingerprint blockers a browser might be running and to detect spoofed properties. I'm not sure how valid this information is however.

1 Answers

This topic is new to me so this is likely not exhaustive:

The W3C provides a Privacy Section on Service Workers that contains the following:

Service workers introduce new persistent storage features including scope to registration map (for service worker registrations and their service workers), request response list and name to cache map (for caches), and script resource map (for script resources). In order to protect users from any potential unsanctioned tracking threat, these persistent storages should be cleared when users intend to clear them and should maintain and interoperate with existing user controls e.g. purging all existing persistent storages. src

Looking at some example of code from Google, it seems that a service worker can declare any number of files to cache during its install event

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open('v1').then((cache) => {
      return cache.addAll([
        './sw-test/',
        './sw-test/index.html',
        './sw-test/style.css',
        './sw-test/app.js',
        './sw-test/image-list.js',
        './sw-test/star-wars-logo.jpg',
        './sw-test/gallery/',
        './sw-test/gallery/bountyHunters.jpg',
        './sw-test/gallery/myLittleVader.jpg',
        './sw-test/gallery/snowTroopers.jpg'
      ]);
    })
  );
});

src

It's seems conceivable that any of files cached by the service could contain a user identifying fingerprint for further tracking.

A related threat, not directly related with Service Workers but closely coupled, are exploits within the manifest.json file.

It's conceivable that the start_url could be crafted to indicate that the application was launched from outside the browser (e.g., "start_url": "index.html?launcher=homescreen"). This can be useful for analytics and possibly other customizations. However, it is also conceivable that developers could encode strings into the start_url that uniquely identify the user (e.g., a server assigned UUID). This is fingerprinting/privacy sensitive information that the user might not be aware of.

Given the above, it is RECOMMENDED that, upon installation, or any time thereafter, a user agent allows the user to inspect and, if necessary, modify the start URL of an application. src

Further Reading

I found at least 1 SO post attempting to incorporate fingerprintjs2 into a Service Worker:

I found this blog post on how to use Google Analytics to collect both online and offline user metrics in PWAs using Service Workers.

Related