You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
andXMLHttpRequest
.This is an in-complete list with types of requests that will be difficult
(or impossible) to cover without webRequest API:
<img>
,<script
)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 isintentionally 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.
The text was updated successfully, but these errors were encountered: