Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

non-blocking webRequest use case - WhoTracks.Me #157

Open
chrmod opened this issue Feb 3, 2022 · 0 comments
Open

non-blocking webRequest use case - WhoTracks.Me #157

chrmod opened this issue Feb 3, 2022 · 0 comments
Labels
topic: dnr Related to declarativeNetRequest

Comments

@chrmod
Copy link

chrmod commented Feb 3, 2022

A use-case for non-blocking webRequest API in extensions is to monitor
requests made from a website. It allows to identify tracking and to provide transparency
on the web. Also, to identify websites that leak private data without the user's consent
(intentionally or unintentionally).

Example 1: WhoTracks.Me (public, crowdsourced data)

An example of crowsourced data is the open data set published on whotracks.me.
It is used to improve the development of tools to prevent tracking, but it is
also used by journalists, researchers and even publishers and advertisers. It is built from the data that is shared
by users all around the world using a variety of browser. That is important, as
the alternative of running servers to simulate website requests introduces
unintended biases (e.g. website look different based on the IP, the locale,
installed extensions).

Example 2: Local Sheriff (local inspection)

There are other related use cases where the data is only locally aggregated
and then allows the user to inspect it to search for leakages of private data.
An example would be the Local sheriff extension
(https://github.com/ghostery/local-sheriff).

In both cases, the functionality is built on-top of the (non-blocking)
webRequest API.

Options and limitations of alternatives implementation techniques

Without the webRequest API, extensions can try to monitor requests by monkey
patching APIs, such as fetch and XMLHttpRequest.

This is an in-complete list with types of requests that will be difficult
(or impossible) to cover without webRequest API:

  • beacon requests
  • requests from HTTP elements (e.g. <img>, <script)
  • requests from a web workers

Even for request that can be covered, the browser will modify requests before sending
them out. For example, the Cookie header will be filled by the browser and is
intentionally not visible to the APIs.

Summary

Of course, it is difficult to prove that no solution exists. Still, there are
justified concerns that it will be infeasible to cover all cases without
built-in support from the browser. It is likely that trackers
will find ways around detection and end up being invisible. As a result,
extensions will no longer be able to provide transparency on the web.

Users will be forced to use proxies, but - for good reasons! - modern browsers
make it difficult to monitor encrypted data. Overall, it will result in an internet
that is less transparent then today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: dnr Related to declarativeNetRequest
Projects
None yet
Development

No branches or pull requests

2 participants