Skip to content

Commit

Permalink
Update src/_blog/2023-ipfs-companion-MV3-update.md
Browse files Browse the repository at this point in the history
Co-authored-by: Marcin Rataj <[email protected]>
  • Loading branch information
whizzzkid and lidel authored Nov 29, 2023
1 parent 1627a48 commit c44ef3f
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion src/_blog/2023-ipfs-companion-MV3-update.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ Chrome's changes have been much more invasive, as they push for the use of backg

When MV3 changes got announced, there was [uproar in the community](https://arstechnica.com/gadgets/2022/09/chromes-new-ad-blocker-limiting-extension-platform-will-launch-in-2023/) that the `webRequest` API was going to be deprecated and replaced by `declarativeNetRequest`. The main reason for this was that the `declarativeNetRequest` API is not as powerful as the `webRequest` API, and it doesn't allow extensions to block requests. Instead, it allows the extension to add and update a limited number of rules per-extension. This was promoted as a way to improve performance and privacy, as the browser would be able to block requests without having to load the extension's code. However, this also meant that the extension would not be able to intercept the requests, and would have to rely on the browser to do so that too for a very limited number of domains.

However, it turns out that the `declarativeNetRequest` API is not as secure as it sounds, because even though the extension cannot intercept or block a request in-flight, it can still observe the request and add or update a rule based on a given observation. Which means a malicious extension can still observe the requests and send them to a remote server for analysis, which is not very different from what the `webRequest` API allows.
In practice, there are no privacy or security benefits of `declarativeNetRequest`, and the old behaviour (required by IPFS Companion) can be reimplemented with extra steps. Even though the MV3 extension cannot intercept and block a request in-flight, it can still observe all HTTP requests without blocking them, and work-around rule count limit by adding or updating dynamic rules on the fly. When a matching request is found by read-only observer, extension can programmatically reload document to force fresh page load against updated dynamic rules. In other words, the MV3 version of Companion extension can emulate the behaviour from MV2:

![declarativeNetRequest API](../assets/ipfs-companion-mv3-declarativenetrequest.png)

Expand Down

0 comments on commit c44ef3f

Please sign in to comment.