Title: Measurement of JavaScript API usage on the web 
Date: 2021-03-30 14:00 
Series: JavaScript API usage 

The world wide web is a complex environment. Web pages can access many APIs
ranging from text formatting to access to nearby Bluetooth devices. While many
APIs are used for legitimate purposes, some are misused to track and identify
their users without their knowledge. In this paper, we propose a methodology to
measure the usage of JavaScript APIs on the public web. The methodology consists
of an automated visit of several thousand websites and intercepting JavaScript
calls performed by the pages. We also provide a design and architecture of a
measurement platform that can be used for an automated visit of a list of
websites. The proposed platform is based on OpenWPM. The browser is instrumented
by OpenWPM and a customized Web API Manager extension is responsible for
capturing JavaScript API calls.

### Introduction

Web browsers offer a wide range of possibilities. on the surface they *just*
display web pages, but under the hood, web browsers provide a bridge between
a viewed page and the host operating system. A web browser allows a web page to
access information like values from sensors, information about battery status,
installed fonts, and much more. The advertisement industry often takes advantage
of the wide range of information provided by web browsers to create a web
browser [fingerprint](https://amiunique.org/links). Most commonly, the
fingeprinters misuse Web APIs (also called JavaScript APIs).

This blog post is mainly concerned with user tracking and fingerprinting. For
example Battery Status API implementation on Mozilla Firefox revealed very
precise value allowing the trackers to identify the user for a [period of
time](https://petsymposium.org/2017/papers/hotpets/batterystatus-not-included.pdf).
As the Battery Status API was used heavily for fingerprinting, it has been
removed from Mozilla Firefox in 2017. Other examples of JavaScript APIs that are
used often for fingerprinting are [Canvas
API](http://cseweb.ucsd.edu/~hovav/papers/ms12.html), [Audio
API](https://senglehardt.com/papers/princeton_phd_dissertation_englehardt.pdf),
[Permissions API](https://arxiv.org/abs/2008.04480) or [APIs for device
sensors](https://dl.acm.org/doi/10.1145/3243734.3243860).

In our work, we aim to measure the JavaScript APIs usage by popular websites. In
this article, we present core technologies to accomplish these measurements. The
stack of technologies is based on [OpenWPM](https://github.com/mozilla/OpenWPM)
enriched by a browser extension, that allows us to intercept JavaScript calls of
different APIs. This browser extension is based on Proxy objects.

Our work is based on work of [Peter Snyders et
al.](https://www3.cs.uic.edu/pub/Bits/PeterSnyder/Browser_Feature_Usage_on_the_Modern_Web.pdf)
carried in 2016. Since then many new APIs were specified and implemented in web
browsers, see the figure below (based on data from [Can I Use?
website](https://caniuse.com/)).

![Progress of Web APIs amount implemented in distinct browsers in
time.]({attach}/images/crawling-apis.png)

### Methodology proposal

This section describes the methodology that we plan to use. This methodology is
based on As it is based on the work of Peter Snyders, it is already validated.
Moreover, using a methodology that is very close to the original one should show
us a difference in the usage of the JavaScript APIs in 2016 and 2021.

The main idea of the measurement is to visit several thousands of the most
[popular pages](https://tranco-list.eu/#aboutus) on the internet and intercept
as many JavaScript calls as possible.

Visiting websites will be performed through Mozilla Firefox with an extension
that intercepts and logs the JavaScript calls. We will visit not only the
landing page but also the subset of subpages of each website. From the landing
page, we will extract three links that point to a subpage of a given page. From
each of these three subpages, we will get another three subpage links resulting
in up to 13 pages of a given website being visited. This amount of pages should
be high enough to catch the most of JavaScript calls. We will wait and intercept
JavaScript calls for 30 seconds on each page to wait of API calls performed
during the page load.

Results of our measurements should also provide information about the JavaScript
APIs, that were probably used in a manner, that is not necessary for a page to
be working and is very likely used in a way, that the user would not find
useful. To achieve this,

We will run our measurements on every page in two different modes. Firstly, we
will visit the page using the a browser withou adblocker. Later, we will also
employ an adblocker. Hence, the study will show the difference API usage of
regular pages and trackers.

#### The original study

The Snyders' study suggests that some of the JavaScript APIs are extremely
popular and they are used on more than 90% of measured pages (e.g. a well known
`Document.createElement` method from DOM API). On the other hand, there are many
APIs that are used by a minority of measured pages. That being said, almost 50%
of JavaScript APIs implemented in the browser at the time were not used by any
of the measured pages.

The study also suggests that there is no direct connection between the
implementation date of a given JavaScript API in the browser (or by its
specification date by some of the specifications vendors) and its popularity in
using by websites. Concretely, there are some old JavaScript APIs, such as
`XMLHttpRequest` that are still very popular. However, there are also quite new
JavaScript APIs, that are used very frequently (i.e., `Selectors API Level 1`).

The conducted study also measured the pages in two ways - with the ad blocker and
without any ad blocking extension. Results of measurements showed that the
blocking of different JavaScript APIs is not uniform and some APIs are blocked
more often than others. Specifically, 10% of JavaScript APIs were blocked in 90%
of cases resulting in a fact that 83% of APIs were used on less than 1% of
websites when the page was visited with active blocking extension.

#### Web API Manager

Web API Manager is a browser extension, that aims to block explicitly defined
JavaScript APIs. It has been developed by Snyders in 2016 and used in several
studies conducted by [Snyders et
al.](https://www.peteresnyder.com/https://www.peteresnyder.com/).

The original purpose of the Web API Manager is to block explicitly defined
JavaScript APIs. However, in our measurements, we just need to intercept the API
calls, log these calls and delegate the calls to original receivers.

The main principle of Web API Manager is based on Proxy objects. This
metaprogramming technique allows intercepting calls performed on objects. While
the main goal of the Web API Manager extension is to block the calls performed
on objects that belong to particular JavaScript APIs, our goal is only to
intercept these operations and delegate them to their original receivers. We
will use the Log Aggregator interface to log the API calls.

To provide a Web API Manager the list of JavaScript APIs members we need a list
of supported APIs. The APIs implemented in Mozilla Firefox are available as [IDL
files](https://searchfox.org/mozilla-central/source/dom/webidl).

#### Measurement tools

The figure below shows a simplified illustration of the measurement platform.
There is OpenWPM in the middle of the architecture. OpenWPM orchestrates
Selenium and Mozilla Firefox with the proxy-based intercepting Web API Manager.

![image]({attach}/images/crawling-architecture.png)

### The impact on JShelter

Once we have data from our crawling study, we will compare the data with [another
recent
study](https://github.com/uiowa-irl/FP-Inspector/blob/master/Data/potential_fingerprinting_APIs.md).
As already mentioned, we want to develop a fingerprinting detection based on
counting the number of different APIs employed by a page, especially APIs that
are not frequently used for benign purposes. When a fingerprinting attempt is
identified, we want to (1) inform the user, (2) prevent uploading of the
fingerprint to the server, (3) prevent storing the fingerprint for later usage.
