arXiv:2110.11241v2 [cs.NI] 29 Mar 2022

Measuring the (Over)use of Service Workers for

In-Page Push Advertising Purposes

George Pantelakis

, Panagiotis Papadopoulos

Nicolas Kourtellis

, and Evangelos P. Markatos

FORTH/University of Crete,

Telefonica Research, Barcelona, Spain

Abstract. Rich oﬄine experience, periodic background sync, push no-

tiﬁcation functionality, network requests control, improved performance

via requests caching are only a few of the functionalities provided by the

Service Worker (SW ) API. This new technology, supported by all major

browsers, can signiﬁcantly improve users’ experience by providing the

publisher with the technical foundations that would normally require a

native application. Albeit the capabilities of this new technique and its

important role in the ecosystem of Progressive Web Apps (PWAs), it is

still unclear what is their actual purpose on the web, and how publishers

leverage the provided functionality in their web applications.

In this study, we shed light in the real world deployment of SWs, by

conducting the ﬁrst large scale analysis of the prevalence of SWs in the

wild. We see that SWs are becoming more and more popular, with the

adoption increased by 26% only within the last 5 months. Surprisingly,

besides their fruitful capabilities, we see that SWs are being mostly used

for In-Page Push Advertising, in 65.08% of the SWs that connect with

3rd parties. We highlight that this is a relatively new way for advertisers

to bypass ad-blockers and render ads on the user’s displays natively.

Keywords: Service Workers, Push Ads, Push Notiﬁcation Advertising

1 Introduction

The proliferation of, and our ever-increasing reliance on, the Web have boosted

the development of more complex and user-friendly Web applications that can

operate cross-platform (on both desktop and mobile Web). Recent advancements

in the contemporary browsers and in the availability of technologies like the SW

API have 1) enabled users to receive timely updates via push notiﬁcations, 2)

their content synced on the background, 3) improved performance (via request

caching) and 4) even allowed to work oﬄine.

These rich capabilities of SWs played an important role in the birth and

growth of a whole separate type of application software called Progressive Web

Apps (PWAs) [1]. PWAs are built on top of three requirements: HTTPS, SWs

and a web app manifest. By combining functionalities of diﬀerent web APIs (e.g.,

WebRTC, Cache API, Push API), PWAs are capable of providing the beneﬁts

arXiv:2110.11241v2 [cs.NI] 29 Mar 2022

of both native apps and websites worlds: reliability, rich user experience, and

multi-platform support via a single codebase [2].

The somewhat revolutionary functionality of SWs could not avoid drawing

the attention of the academic community with regards to its security aspects.

Speciﬁcally, research studies have shown that this technology provides rich capa-

bilities not only to users and web developers, but to potential attackers as well.

In [3], authors present a framework that exploits SWs functionality to launch

attacks like DDoS, cryptojacking and distributed password cracking. In [4], au-

thors investigate the potential privacy leaks that malicious SWs can cause on a

victim’s browser.

Notwithstanding the important research on the SW API, yet it is still un-

known what is the prevalence and the growth of the SW deployment across

the Web and how publishers leverage the provided functionality of SWs in their

Web applications. In this study, we aim to address these exact questions, by

conducting a full-scale analysis of SWs (the core component of PWAs) in the

wild. Speciﬁcally, we crawl a large number of websites to detect the deployment

of SWs, monitor and characterize their communications across the Internet, and

investigate their purpose of existence and operation on the websites found.

In summary, the contributions of our present work are:

1. By crawling the top 150K sites of the Tranco list, we detect a dataset of

7,444 SWs-registering websites. The same crawl after 5 months reveals a

high increase (26%) in the adoption of SWs.

2. We use Wayback Machine to go back in time and ﬁnd that, from 2015 till

today, there were 1.62× more publishers per year, on average, utilizing SWs

in their web applications.

3. By analysing our collected dataset, we conduct the ﬁrst full-scale study of

the SWs deployment on the Web. Speciﬁcally, we investigate with whom the

deployed SWs communicate over the Internet, what are the websites that

use such technology the most, as well as what is the purpose of the deployed

SWs. Surprisingly, we see that despite the important functionality of SWs

(e.g., timely notiﬁcations, background sync, etc.), yet a stunning 65.08% of

the SWs that connect with 3rd parties use SWs for pushing ads to the users,

under the radar of possibly deployed ad-blockers.

2 Service Workers

A Service Worker is a JavaScript script that runs separately from the main

browser thread, and can intercept network requests, perform caching or retriev-

ing resources from the cache, and deliver push messages. SWs are independent

from the Web application they are associated with, so they cannot access the

DOM directly. SWs are non-blocking and fully asynchronous. Therefore, syn-

chronous XHR and localStorage cannot be used inside a SW . Also, a SW can

import and execute 3rd party scripts within its context, and receive push mes-

sages from a remote server, thus letting the associated website push notiﬁcations

to the user (even when the website is not open in a browser tab). Finally, a SW

Fig. 1: The Web Push API enables

developers to deliver asynchronous

notiﬁcations and updates to users

who opted-in.

Fig. 2: An in-page push advertise-

ment as it appears on the user’s

screen on top of other windows.

can be registered to the browser via the serviceWorkerContainer.register()

or navigator.serviceWorker.register() function, which take as argument

the (HTTPS only) URL of the remote JavaScript ﬁle that contains the worker’s

script. This URL is passed to the internal browser’s engine and is fetched from

there. For security purposes, this JavaScript ﬁle can be fetched only from the

ﬁrst-party domain, i.e., cannot be hosted by a CDN or a 3rd party server.

2.1 Web Push Notiﬁcations

The Web Push API gives web applications the ability to receive messages pushed

from a remote server, whether or not the Web app is in the foreground, or even

loaded in a browser tab. As shown in Figure 1, the Web Push API enables devel-

opers to deliver asynchronous notiﬁcations and updates to (desktop or mobile)

users that opt-in, resulting in better engagement with timely new content. For

an app to receive push messages, it has to have an active SW and subscribe to

push notiﬁcations (each subscription is unique to a SW ). The endpoint for the

subscription is a unique capability URL, and the knowledge of the endpoint is

all that is necessary to send a message to the application’s users. Therefore, the

endpoint URL needs to be kept secret or anyone might be able to send push

messages to the app’s users.

2.2 In-Page Push Advertising

Web push notiﬁcation technology itself is nothing new, but it has started to be

used for advertising purposes very recently. In fact, push marketing skyrocketed

at the end of 2018 [5]. Push ads are a type of native ad format in the form of a

notiﬁcation message from a website, which appears on the user’s screen on top

of other windows as shown in Figure 2. Users who click on those messages get

redirected to the advertiser’s landing page, thus, generating ad-conversion.

The in-page push ad delivery is cross-platform and aims to oﬀer an opt-in

based, highly engaging way for advertisers to reconnect and expand their audi-

ences, while at the same time it achieves higher click-through and conversion

Site visit

Web Server

Webpage fetch

Browser

Ad Blocker

Cloud Messaging

Platform

Subscribe to push

notifications

Third party

server

Webpage

Service Worker

Notification

Consent

Display

Notification

Push Ad

Messages

Fig. 3: High level overview of how SWs deliver push ads on the user display

even with ad blocker deployed.

rates than other ad formats [6]. A push notiﬁcation usually consists of: (i) the

main image which conveys the sense of the ad impression, (ii) the small icon

which explains the main image, (iii) the headline which is the main element

to engage users and (iv) the message text that shows the main details of the

oﬀer. Contrary to traditional programmatic advertising [7,8,9], in push ads, ad-

vertisers pay for clicks (i.e., Cost-Per-Click) and not for impressions (i.e., Cost-

per-Impression). The minimum cost per click starts from $0.0104 [10], but in

Real-Time Bidding the median cost per impression has been measured to be as

low as $0.0025 [11].

3 Use Case

In Figure 3, we present a high level overview of how SWs and push notiﬁcations

work. As we can see, ﬁrst (step 1), the user visits a website they are interested in,

thus, instructing a browser to connect with a web server (step 2) that responds

back with the web page’s HTML/CSS/JavaScript resources, along with a SW

script, which gets registered (step 3). This snippet will deploy a SW inside the

user’s browser (step 4) which operates independently from the rendered website.

Then, the SW will ask the user’s permission to push notiﬁcation massages on

their display (step 5) and if granted, it will establish a communication chan-

nel with a remote messaging platform to subscribe to their push notiﬁcations

(step 6). Whenever the message publishing entity (e.g., news update feed server,

article recommendation server, ad server) behind the messaging platform has

updates to push to the website’s users, it uploads them to the platform which

will push them to all subscribed users (step 7). On the user’s end, upon message

Table 1: Summary of our dataset

Data Volume

Websites parsed 150K

(1st crawl, 12.20) Websites registering a SW (SW) 7,444 (4.96%)

SWs that do not communicate with any remote server 336 (4.51%)

SWs communicating only with the ﬁrst party 2,054 (27.59%)

SWs communicating with at least one 3rd party 5,054 (67.89%)

SWs communicating with at least one ad server 3,289 (44.18%)

SWs communicating with at least one analytics server 164 (3.24%)

(2nd crawl, 05.21) Websites registering a SW 9,383 (6.25%)

arrival, the deployed SW creates a push notiﬁcation with the received message

on the user’s display (step 8). As shown, a SW may establish a separate commu-

nication channel with a remote messaging platform that cannot be monitored or

ﬁltered by any potentially deployed ad-blocking browser extension. This means

that whenever a user opts-in to receive updates from a website, they may start

receiving ad notiﬁcations instead, even if they have an ad-blocker deployed.

4 Data Collection

Crawling infrastructure After manual inspection, we see that there are web-

sites checking ﬁrst if the site has push notiﬁcation permissions, before registering

SWs. This means that in order to perform a large scale crawl of websites and

detect the deployment of SWs, and the use of push notiﬁcations, some sort of

automation for the notiﬁcation consent is required. To address this, we leverage

the crawler presented in [12]. This crawler creates docker containers with fresh

instrumented Chromium browser instances and browser automation scripts. The

browser has the RequestPermission and PermissionDecided methods of the class

Permission-ContextBase, modiﬁed to automatically grant permissions on every

site. Then, a custom Puppeteer [13] script listening to serviceworkercreated event

is used to log when a SW is registered by a website, the page that registered

this SW and the URI of the source code. As soon as a SW is registered, it can

subscribe for push notiﬁcations via a Cloud Messaging Platform (e.g., Firebase

Cloud Messaging [14]) with an API key passed from the server to the browser,

which is also logged by listening for PushManager.subscribe events. Then, the

custom Puppeteer script logs the communication between the SW and the Web.

Creating the Dataset We create a dataset of websites that utilize SWs, by

crawling the landing pages of the 150K top sites of a (deduplicated, pay-level

only domains) Tranco list [15] in December 2020. Each site is visited for three

minutes, during which, and according to our experiments, is suﬃcient for a SW

to be register and make the ﬁrst touch with the corresponding server(s) (1st

crawl). After 5 months (April 2021), we revisit the websites of our initial Tranco

10%

15%

20%

25%

30%

35%

40%

News and Media

Computers Electronics

and Technology

TV Movies and

Streaming

Adult

Fashion and Apparel

Programming and

Developer Software

Finance

Education

Video Games Consoles

and Accessories

Arts and Entertainment

Percentage of sites

Top Content Categories

sites with SW

22.05%

6.27%

3.50%

3.32%

3.18%

2.68%

2.41%

2.29%

2.23%

2.19%

sites with SW fetching ads

27.00%

6.42%

4.37%

4.79%

2.32%

2.29%

2.78%

2.19%

1.70%

2.01%

Fig. 4: Top 10 content categories of sites using (i) SWs (blue) and (ii) SWs

that communicate with advertisers (red). As we can see, SWs is a technique

widely used in sites delivering content related to ‘News and Media’ and

‘Computers Electronics and Technology’.

list to inspect how the ecosystem evolved, i.e., sites dropping SWs, new sites

adopting SWs (2nd crawl). Table 1 summarizes the data collected.

Data analysis To classify the network traﬃc of the registered SWs in our data,

we use the 1Host ﬁlterlist [16] and ﬂag the ad-related domains in our weblogs.

Additionally, we used SimilarWeb [17] to categorize the sites registering SW

based on the content they deliver.

Historical analysis and static detection To explore the evolution of SWs

across time, we use our set of SW -registering sites to extract heuristics and

keywords that indicate the registration or use of SWs. This way, we develop a

crawler that can statically detect the registration of SWs in this set of sites. Next,

we use Wayback Machine [18], and speciﬁcally waybackpy Python package [19]

to go back in time and ﬁnd the day that these websites started deploying SWs

in their visitors’ browsers.

Ethical Considerations It is important to note that during the conduct of

this study, we neither gathered or used any user data, nor impeded or tampered

with the proper operation of the sites we crawled, in any way. Our research was

purely limited in passively monitoring the behavior of SWs.

5 Measurements

What are the kind of sites deploying SWs? By crawling the top 150K

websites of the Tranco list, we ﬁnd that 7,444 (4.96%) of these sites register

one or more SWs in the users’ browser (Table 1). To understand what kind of

0.0x

0.5x

1.0x

1.5x

2.0x

2.5x

2016 2017 2018 2019 2020 2021

Growth factor of new websites

deploying SWs

Year

Fig. 5: Growth factor of the SWs deployment in our dataset. From 2015 till

mid 2021, there are 1.62× more publishers per year, on average, utilizing

SWs in their Web apps.

sites deploy such a technique, we query Similarweb [17] for the content category

of each of our sites and we get a response for 86.7% of them. In Figure 4, we

plot the top-10 categories. We see that the sites that mostly use SWs (in blue)

are related to ‘News and Media’ (22.05%), with the categories of ‘Computers

Electronics and Technology’ and ‘Arts and Entertainment’ following (6.27% and

3.5%, respectively).

What is the prevalence of SW deployment? By revisiting the sites of

the same Tranco list after 5 months (as described in Section 4) via the same

crawler, we ﬁnd a total of 9,383 websites registering a SW (6.25% of the total

sites crawled), which indicates a 26% increase. More speciﬁcally, we ﬁnd (i) 6,173

websites using SWs in both crawls, (ii) 1,271 websites that stopped using them

at some time after our 1st crawl, and (ii) 3,210 new websites deploying them in

their visitors’ browsers.

This rapid growth in the prevalence of SWs within just 5 months, motivated

us to go back in time and observe their evolution across the years. Speciﬁcally,

by using Wayback Machine web archive [18] and our initial set of SW -registering

websites, we crawled previous versions of their landing pages to spot when they

started using SWs. As a result, we crawled all the way back to 2015, when the

ﬁrst websites in our dataset started using SWs. As seen in Figure 5, after 2015,

every year we observe an average growth factor of 1.62. In 2017 and 2018 we

see this growth increasing, with 2.09× and 2.14× more websites deploying SWs

than the previous year, respectively.

What is the communications between SWs and Web? Next, by analyzing

the traﬃc that the registered SWs generate, we see that 27.59% communicate

only with the ﬁrst party. However, 67.89% of them communicate with at least one

3rd party, and 4.51% of them do not communicate with the web at all (Table 1).

In Figure 6, we plot the number of distinct 3rd parties each registered SW in

10%

20%

30%

40%

50%

60%

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 26

Percentage of registered SWs

Unique third party domains

32.11%

51.59%

11.32%

2.11%

1.07%

0.54%

0.44%

0.23%

0.20%

0.17%

0.03%

0.05%

0.01%

0.05%

0.03%

0.01%

16.3%

Fig. 6: The number of distinct 3rd parties each SW communicates with.

32.1% of the SWs do not communicate with a 3rd party. The majority

(51.6%) communicates with exactly one 3rd party. 16.3% communicate with

2 or more (even 26!) distinct 3rd parties.

our dataset communicates with. As we can see, 32.1% of the SWs communicate

with no 3rd party (as mentioned: 27.59% connects with the ﬁrst party only, and

4.51% with no one), when the majority (51.6%) communicates with exactly one

3rd party, proving that there are speciﬁc agreements between publishers and

3rd party advertisers, analytics, content or library providers. It is important to

note that there is a signiﬁcant 16.3% communicating with 2 or more (even 26!)

distinct 3rd parties.

How much do SWs support Push Advertising? By using the popular

ﬁlter-list of 1Hosts, we classify the type of domains the SWs connect with in our

dataset. Surprisingly, as we see in Figure 7, in essence 3rd party communications

of SWs are used for advertising, since the majority (65.08%) of the SWs that

connect with 3rd parties, establish these connections to receive content from at

least one push advertiser (9.51% receive content from 2 advertisers or more).

On the contrary, only 34.92% of the SWs perform at least one request to 3rd

parties, but communicate with zero ad servers.

What is the popularity of sites leveraging Push Advertising? In Fig-

ure 8, we plot the popularity rank of the websites that deploy SWs on the users’

side. As we see, the sites that tend to deploy ad pushing SWs are of lower

popularity ranks in comparison to the ones that use SW only locally, without

connecting to any remote server. Speciﬁcally, the median site that registers SW

that does not connect with any remote server has a popularity rank of around

40000 in Tranco (grey). On the other hand, the median site with SW that con-

nects (i) only with ﬁrst party domains, or with 3rd parties that do not include

ads is around 50000 rank (green or orange) (ii) with push ad domains around

60000 rank (red).

20%

40%

60%

80%

100%

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14

Percentage of registered SWs

Unique push ad domains

34.92%

55.58%

6.47%

1.17%

0.46%

0.65%

0.38%

0.12%

0.08%

0.06%

0.04%

0.02%

65.09%

9.51%

Fig. 7: Number of distinct push ad

3rd parties each SW communicates

with. 65.08% of SWs communicate

with 3rd parties and receive content

from at least one push advertiser.

34.92% of SWs perform at least one

request to 3rd parties but communi-

cate with zero ad servers.

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

0 20 40 60 80 100 120 140

Median

CDF

Popularity rank (10

)

SWs not connecting with any server

SWs connecting with only 1st parties

SWs connecting with 3rd parties (not ads)

SWs connecting with 3rd party (ads)

Fig. 8: Cumulative distribution func-

tion of the popularity rank of the

websites with SWs. As we see, the

sites that tend to deploy ad push-

ing SWs are less popular than the

ones that use SW only locally, and do

not connect to any remote 3rd party

server.

Also, as we see in Figure 4 (in red) where we consider only sites with SWs

that communicate with ad servers, the content categories are topped by ‘News

and Media’ (27%), ‘Computers, Electronics and Technology’(6.42%) and ‘Adult’

(4.79%). This is somewhat expected, since ‘News and Media’ sites have higher

chances to convince a user to give their consent to receive timely news updates

via push notiﬁcations, that can also include ads.

In Figure 9, we further analyze these content categories by selecting their

sites in our dataset that communicate with 3rd parties via their deployed SWs.

Then, we measure what portion of them does that for advertising purposes. We

see that Soccer sites lead this eﬀort, with a percentage close to 85%. This means

that from all Soccer sites using SWs to communicate with 3rd parties, 85% use

them to communicate speciﬁcally with at least one ad server. The ‘Animation

and Comics‘ follow closely with 84% and ‘File Sharing and Hosting’ are next,

with 83.78%. The ‘News and Media’ are in ﬁfth place with a bit more than 77%.

These high portions suggest that 75-80% of these websites use SWs for ads.

One can not help but wonder why were SWs invented in the ﬁrst place. It

is true that several people may argue that SWs were invented to provide oﬄine

operation, synchronize data in the background, and retrieve updates. However,

we see a diﬀerent picture here: SWs that communicate with 3rd parties are pri-

marily used for advertisements, thus opening a new way to reach users’ desktop:

a way invented for a diﬀerent purpose. Even if these push notiﬁcations require

user to give consent, the website is free to abuse this consent at any time by

delivering ad messages instead of the news updates the user was interested in

receiving. These ad messages appear via the SWs as native ads and cannot be

controlled (or ﬁltered out) by ad-blockers. One can only smile in melancholy at

20%

40%

60%

80%

100%

Soccer

Animation and

Comics

File Sharing

and Hosting

Adult

News and Media

TV Movies and

Streaming

Sports

Science and

Education

Investing

Computers Electronics

and Technology

Percentage of sites

Top Content Categories

84.6%

84.4%

83.8%

77.1%

75.1%

74.6%

71.8%

71.0%

70.3%

69.5%

Fig. 9: Breakdown the top-10 cate-

gories for sites using SWs to serve

ads. ‘Soccer’ sites are the most ag-

gressive in using SWs for adver-

tising (84.62%), with ‘Animation

and Comics’ and ‘File Sharing and

Hosting’ following. ’News and Me-

dia’ sites are next (75%).

10%

100%

onesignal.com

izooto.com

subscribers.com

najva.com

sendpulse.com

truepush.com

webpushr.com

aswpsdkus.com

dislanelibrar.top

p-n.io

Percentage of sites

Push Ad Networks

37.5%

3.9%

3.8%

3.7%

2.9%

2.6%

2.3%

1.9%

Fig. 10: Portion of unique sites col-

laborating with each of the top

ad servers in our dataset. ones-

ignal.com dominates the market

(37.49%) with the majority of the

rest of the ad servers owning less

than 4% each (note: y-axis in log-

scale).

the Google Developers guide advising: “Whatever you do, do not use notiﬁca-

tions for advertising of any kind.”

Which are the dominant Push Ad Networks? In Figure 10, we plot the

top 10 most popular Push Ad Networks in our data, and the portion of the

registered SWs they communicate with. We see that onesignal.com dominates

push advertising by owning more than 37.49% of the market, with the majority

of the rest Push Ad Networks owning less than 4% each. In Figure 11, we plot

the distribution of all push ad networks in our dataset along with the sites they

deliver push ads to. We can see that the distribution can be modeled by two

straight lines for large numbers in the x-axis, indicating that the distribution

has a piece-wise power-law tail. We can also see the head representing the major

player onesignal.com.

6 Related Work

The powerful technology of Service Workers provides rich functionality to de-

velopers and has triggered an important body of research around its security

and privacy aspects. Papadopoulos et al. in [3] are the ﬁrst to study SWs in

an attempt to raise awareness regarding a new class of attacks that exploit this

exact HTML 5 functionality. Speciﬁcally, the authors investigated the potential

security vulnerabilities of SWs and they demonstrated multiple attack scenar-

ios from cryptojacking to malicious computations (e.g., distributed password

cracking), as well as Distributed Denial of Service attacks.

https://developers.google.com/web/ilt/pwa/introduction-to-push-notiﬁcations

-0.73

-1.53

Number of Sites

Rank of Push Ad Networks

Fig. 11: Distribution of the number of sites that each Push Advertiser in our

dataset delivers ad notiﬁcations to. The points in the plot tend to converge

to two straight lines for large numbers in the x axis, following a piece-wise

power-law distribution.

Karami et al. in [4] studied attacks that aim to exploit SWs vulnerabilities to

ex-ﬁltrate important privacy information from the user. Speciﬁcally, they demon-

strated two history-sniﬃng attacks that exploit the lack of appropriate isolation

in these browsers including a non-destructive cache-based version. Finally, the

authors proposed a countermeasure and developed a tool that streamlines its

deployment, thus facilitating adoption at a large scale.

Chinprutthiwong et al. in [20] described a novel Service Worker-based Cross-

Site Scripting (SW-XSS) attack inside a SW , that allows an attacker to obtain

and leverage SW privileges. Additionally, they developed a SW Scanner to an-

alyze top websites in the wild, and they found 40 websites vulnerable to this

attack including several popular and high ranking websites. Squarcina et al.

in [21] demonstrated how a traditional XSS attack can abuse the Cache API

of a SW to escalate into a person-in-the-middle attack against cached content,

thus, compromising its conﬁdentiality and integrity.

Subramani et al. in [12] proposed PushAdMiner: a new tool to detect Web

Push Notiﬁcations (WPNs) on the Web. Contrary to our work, the authors focus

only on ad related WPNs messages by collecting and analyzing 21,541 WPN

messages and 572 ad campaigns, for a total of 5,143 WPN-based ads reporting

51% of them as malicious. Finally, Lee et al. in [22] conducted a systematic study

of the security and privacy aspects of PWAs. They demonstrated a cryptojacking

and a browser history exﬁltration attack. They also suggested possible mitigation

measures against the vulnerabilities of PWAs and corresponding SWs.

7 Summary & Conclusion

In this paper, we set out to explore the ecosystem of Service Workers and how

websites overuse them to deliver ads (even when user has deployed ad-blockers).

We analyzed the top 150K websites of the Tranco list and our ﬁndings can be

summarized as follows:

1. A non-trivial percentage (4.96%) of sites deploy a SW on the user side.

2. Within a period of 5 months (12.20-05.21), there has been a 26% increase in

the adoption of SWs.

3. Overall, by using Wayback Machine, we found that from 2015 till today,

there were 1.62× more publishers per year, on average, utilizing SWs in

their web applications.

4. 32.1% of the SWs communicate with no 3rd party (27.59% connects with

its ﬁrst party only and 4.51% connects with nobody). The majority (51.6%)

communicates with exactly one 3rd party with a signiﬁcant 16.3% commu-

nicating with 2 or more (and up to 26) distinct 3rd parties.

5. Third-party communications are mostly for pushing ads: A stunning

65.08% of the registered SWs that communicates with 3rd party

servers, communicate with at least one advertiser.

6. Most of the ads-pushing SWs are deployed on ‘News and Media’ related

sites (27%), with the ‘Computers, Electronics and Technology’ (6.42%), and

‘Adult’ (4.79%) related sites following.

7. For some website categories such as ‘Soccer’ and ‘File Sharing’, the percent-

age of ads-pushing SWs reaches as high as 85%.

Our study on Service Workers has revealed several surprising results with

respect to the use of SWs on Web applications and websites. Future research

could look into leakage of user personal information and tracking from SWs, as

well as how ad-blockers can be revamped to still provide eﬀective ad-ﬁltering to

their end-users.

Acknowledgements

This project received funding from the EU H2020 Research and Innovation pro-

gramme under grant agreements No 830927 (Concordia), No 830929 (Cyber-

Sec4Europe), No 871370 (Pimcity) and No 871793 (Accordion). These results

reﬂect only the authors’ view and the Commission is not responsible for any use

that may be made of the information it contains.

References

1. Google Developers. Progressive web apps. https://web.dev/progressive-web-

apps/#introduction, 2017.

2. Pete LePage Sam Richard. What are progressive web apps? https://web.dev/

what-are-pwas/, 2020.

3. Panagiotis Papadopoulos, Panagiotis Ilia, Michalis Polychronakis, Evangelos P

Markatos, Sotiris Ioannidis, and Giorgos Vasiliadis. Master of web puppets: Abus-

ing web browsers for persistent and stealthy computation. In Network and Dis-

tributed System Security Symposium (NDSS), 2019.

4. Soroush Karami, Panagiotis Ilia, and Jason Polakis. Awakening the web’s sleeper

agents: Misusing service workers for privacy leakage. In Network and Distributed

System Security Symposium (NDSS), 2021.

5. Marry Ann. Are push notiﬁcations high engagement marketing tool

in 2018? https://themarketingfolks.com/are-push-notifications-high-

engagement-marketing-tool-in-2018/, 2021.

6. New brave ads use cases show up to 15.8% click-through rate, unmatched engage-

ment. https://brave.com/brave-ads-use-cases/, 2020.

7. Panagiotis Papadopoulos, Nicolas Kourtellis, and Evangelos P Markatos. The cost

of digital advertisement: Comparing user and advertiser views. In Proceedings of

the World Wide Web Conference (WWW), 2018.

8. Claude Castelluccia, Lukasz Olejnik, and Tran Minh-Dung. Selling oﬀ privacy at

auction. In Network and Distributed System Security Symposium (NDSS), 2014.

9. Michalis Pachilakis, Panagiotis Papadopoulos, Evangelos P. Markatos, and Nicolas

Kourtellis. No more chasing waterfalls: A measurement study of the header bidding

ad-ecosystem. In Proceedings of the Internet Measurement Conference (IMC),

2019.

10. Aksana Shakal. Push ads in 2021: Complete advertiser’s guide. https://

richads.com/blog/push-notification-advertising/, 2020.

11. Panagiotis Papadopoulos, Nicolas Kourtellis, Pablo Rodriguez Rodriguez, and

Nikolaos Laoutaris. If you are not paying for it, you are the product: How much

do advertisers pay to reach you? In Proceedings of the Internet Measurement Con-

ference (IMC), 2017.

12. Karthika Subramani, Xingzi Yuan, Omid Setayeshfar, Phani Vadrevu, Kyu Hyung

Lee, and Roberto Perdisci. When push comes to ads: Measuring the rise of (ma-

licious) push advertising. In Proceedings of the ACM Internet Measurement Con-

ference (IMC), 2020.

13. Google. Puppeteer: Chormium browser automation tool. https://

developers.google.com/web/tools/puppeteer, 2020.

14. Google Developers. Firebase cloud messaging. https://firebase.google.com/

docs/cloud-messaging, 2021.

15. Tranco. The tranco list we used for our crawls. https://tranco-list.eu/list/

L564/1000000, Created on 24/09/2020.

16. badmojr. 1hosts (pro). https://hosts.netlify.app/Pro/hosts.txt, 2021.

17. Similarweb LTD. Website traﬃc - check and analyze any website. https:

//www.similarweb.com/, 2021.

18. Wayback Machine. Internet archive. https://archive.org/web/, 2021.

19. Akash Mahanty. Python package & cli tool that interfaces with the wayback

machine api. https://pypi.org/project/waybackpy/, 2021.

20. Phakpoom Chinprutthiwong, Raj Vardhan, GuangLiang Yang, and Guofei Gu.

Security study of service worker cross-site scripting. In Annual Computer Security

Applications Conference (ACSAC), 2020.

21. Marco Squarcina, Stefano Calzavara, and Matteo Maﬀei. The remote on the lo-

cal: Exacerbating web attacks via service workers caches. In 15th Workshop On

Oﬀensive Technologies (WOOT), 2021.

22. Jiyeon Lee, Hayeon Kim, Junghwan Park, Insik Shin, and Sooel Son. Pride and

prejudice in progressive web apps: Abusing native app-like features in web ap-

plications. In Proceedings of the ACM SIGSAC Conference on Computer and

Communications Security (CCS), 2018.