Malware / Phishing protection not possible in Manifest V3

[chrmod]

Extension like Malwarebytes Browser Guard and others (disclaimer: I'm not associated or in contact with Malwarebytes in any way) protect their users by blocking potentially harmful websites.

This is typically achieved by comparing the website's domain name with a block list.

The problem is that there are millions of well known rouge domains and this list is constantly changing.
The current limitations of declarativeNetRequest make it impossible to load a complete list:

• GUARANTEED_MINIMUM_STATIC_RULES is set to 30000
• Global limit in current Chrome Canary is set to about 350000 (check with await chrome.declarativeNetRequest.getAvailableStaticRuleCount())
• MAX_NUMBER_OF_DYNAMIC_AND_SESSION_RULES is set to 5000 - so it is too small to keep up with new domains created every day
• When those limits are fully used, the add-on is no longer able to perform other content blocking activities like Ad Blocking, Tracking Protection or Blocking Annoyances.

Manifest V2 addons are able to handle such huge block lists as they typically use optimal data structures like bloom filters. Such bloom filters are typically shipped in a binary form, so they don't require additional processing before being used. That makes them memory and cpu efficient (when compared to JSON we can talk about orders of magnitude in difference). The size of such a bloom filter will likely be around a few megabytes.

Manifest V3 makes usage of such bloom filters impossible:

• chrome.storage.local is too small and likely too slow access as we talk about millions of keys
• chrome.storage.session of 1MB is too small
• Ephemeral service worker makes it impossible to use webRequest, webNavigation or tabs API to detect a rouge domain

For reference, at Ghostery we use bloom filters for our "AI Tracking Protection" https://cliqz.dev/blog/2019-12-19/blocking-tracking-without-blocking-trackers.html - but that use case is limited by the lack of blocking web requests. I will address it in a separate issue.

List limits are a common problem for the declarative blocking approach. Here you can see a discussion on Webkit limits which were recently increased from 50k to 150k per list: https://bugs.webkit.org/show_bug.cgi?id=205719. Note that those limits apply to iOS/iPadOS as well. On Webkit rule limit is set for a single list, there is no global rule limit and extensions can load multiple lists.

[cuylerstuwe]

We also had to drop our anti-phishing protection in MV3, due to these and other constraints which didn't exist in MV2.

I've made this same point elsewhere, but it was buried within a conversation thread. It's good to see someone making a discrete topic of it.

[tophf]

One possible workaround is to produce a single superlong regular expression from all those domains and use it in declarativeNetRequest's regexFilter. There are simple tools around that can optimize such a list so that similar domains reuse their identical parts e.g. www\.(foo|bar)\.com

[cuylerstuwe]

One possible workaround is to produce a single superlong regular expression from all those domains and use it in declarativeNetRequest's regexFilter. There are simple tools around that can optimize such a list so that similar domains reuse their identical parts e.g. www\.(foo|bar)\.com

1. This will likely be prohibitively nonperformant.
2. This doesn't help w/ malware/phishing protection that needs to perform on-the-fly arbitrary calculations of multiple signals in order to estimate risk.

[tophf]

FWIW, I expect it to be much faster than DNR's own check using multiple rules.

[jawz101]

Could some blocking be done by distrusting a site's SSL cert?

[noloader]

Based on my reading of the W3C's Design Principals and Manifest v3 design goals, Manifest v3 is not consistent with the W3C. The conflict arises because the W3C puts the user first as stated in Priorities of Constituencies. However, Manifest v3 puts the website operator and website first.

Manifest v3 should be categorically rejected by the W3C.

If Google wishes to privately pursue its agenda, then that is Ok. Organizations are welcomed to side-load a modified browser that implements Manifest v3. Organizations are free to do what they want.

[dotproto]

The conflict arises because the W3C puts the user first as stated in Priorities of Constituencies. However, Manifest v3 puts the website operator and website first.

I don't agree with your assessment that Manifest V3 prioritizes websites over users. Can you substantiate that claim?

Manifest v3 should be categorically rejected by the W3C.

The W3C does not endorse and community groups are not part of W3C's standards process.

If Google wishes to privately pursue its agenda, then that is Ok. Organizations are welcomed to side-load a modified browser that implements Manifest v3. Organizations are free to do what they want.

Manifest V3 was publicly available in Chrome before this community group was created. Chrome was privately pursuing it's agenda. Manifest V3 is a relevant concern for this group because it was (and is) an active area of development for one of the participating browser vendors.

One of the main reasons this group was created was to seek alignment across browsers on WebExtensions capabilities and APIs. In some cases browser vendors will disagree: for example, Safari and Firefox have indicated that they plan to support both event pages and service workers as an extension's background context while Chrome only allows service workers. Disagreement between Manifest V3's original design goals and this group's stated design principals does not mean that we shouldn't be talking to each other about how to evolve browser extension implementations across browsers.