declarativeNetRequest API: have `isUrlFilterCaseSensitive` condition set to `false` by default

[gorhill]

Currently, the isUrlFilterCaseSensitive condition defaults to true when not specified.

I propose the default state to be changed to false.

Content blockers are probably behind the largest rulesets which will feed into the declarativeNetRequest API, and top content blockers are compatible and abide by EasyList syntax. In EasyList syntax, the pattern matching is case-insensitive by default, and the match-case option is rarely used.

At the moment, I find zero instance of match-case in EasyList and EasyPrivacy. I find 23 instances in uBlock Origin's own filter lists, and 5 instances in AdGuard's English list.

Defaulting isUrlFilterCaseSensitive to false would avoid the need to encode the property for the vast majority of rules, and thus reduce the size and verbosity of ruleset files.

For example, when I convert the default filter lists of uBO into a json ruleset file, the result is ~3.7 MB, while it is ~3 MB when assuming isUrlFilterCaseSensitive default to false (this was a single unformatted line of json).

[xeenon]

I support this from Apple. Our internal format already is case-insensitive by default.

[dotproto]

Thanks for the feedback, @gorhill. My first impression is that this seems like a good change. I suspect that the main challenge here is going to be breaking published extensions, tough we may be able to largely mitigate this through public announcements and direct outreach.

[zombie]

Firefox also support this proposal, the risk of "breaking" existing extensions here seems minimal, as the new default would be to block more. It seems likely that those who care about case sensitivity would explicitly use the true condition, and those that don't (want/care about case sensitivity) would be less likely to include the explicit value for this condition.

[Rob--W]

Firefox has already implemented this default: https://bugzilla.mozilla.org/show_bug.cgi?id=1811498

Safari has already filed a tracking issue internally.

Chrome will also file such a bug.

Relevant part of yesterday's meeting notes:

https://github.com/w3c/webextensions/blob/9c2609a29c07c3b0d2652d5f6079b2984a93b7b0/_minutes/2023-01-19-wecg.md?plain=1#L116-L124

[xeenon]

This shipped today in Safari Technology Preview 163.

[dotproto]

I just opened https://crbug.com/1414441 to track this issue in Chromium.

[oliverdunk]

Marking this as https://github.com/w3c/webextensions/labels/supportive%3A%20chrome. Simeon mentioned in a previous meeting (https://github.com/w3c/webextensions/blob/main/_minutes/2023-01-19-wecg.md?plain=1#L119) but we are happy to make this change provided we've done some outreach first to give everyone a heads up. I'm going to look in to that.

[oliverdunk]

We've done an announcement to developers here: https://groups.google.com/a/chromium.org/g/chromium-extensions/c/TXYUmvDHUlw/m/9JdxXG2cAgAJ. We're planning to make this change in M118.

Bug: https://crbug.com/1414441

[oliverdunk]

This shipped in Chrome 118: https://chromiumdash.appspot.com/commit/d90e6a56d0e77ce5d278a5b070098c5d8f7081fd