[ my public key: https://keybase.io/antonok; my proof: https://keybase.io/antonok/sigs/VR_-POMgFiZfvYQj3ZacA_L0Xg_9prKxELr_U0LpeZw ]
- antonok parentYou're probably thinking of Adblock Plus? Acceptable Ads is their program; EasyList has no such policy or ties.
- FlatBuffers was definitely the majority of the improvements here!
On 64-bit systems, pointers themselves can really start to take up a lot of memory (especially if you multiply them across 100k+ adblock filters). Switching to array indices instead of pointers saves a lot of memory that's otherwise wasted when you don't need to address the entire possible memory space.
- I opened an issue based on the discussion here and it didn't take much time or effort.
(It was one of those form-based issue templates that requires you to explicitly list out Steps to Reproduce, Expected behavior, Actual behavior, OS version, etc. which IMO causes slightly more friction for anyone who knows how to put together a good bug report, but I've also seen enough poorly-specified issues to know that it's necessary sometimes)
- I've done it:
https://github.com/penpot/penpot/issues/7850
Thanks for sharing all the details about the issue, and shame on all the armchair critics :D
- If you want to find devices that still need hardware support under Linux, I highly recommend trying to get a mobile Linux distribution to work on an old smartphone or tablet.
postmarketOS in particular has a really good devices page [1] showing missing feature support at a glance, as well as guides for porting to new devices [2] and porting features from an outdated vendor-provided Linux fork to the upstream kernel [3].
[1] https://wiki.postmarketos.org/wiki/Devices [2] https://wiki.postmarketos.org/wiki/Porting_to_a_new_device [3] https://wiki.postmarketos.org/wiki/Mainlining
- Are you referring to the Manifest V2 extensions supported by Brave? The original extension creators were made fully aware of those plans ahead of time and have been in contact with Brave since then, e.g.:
https://github.com/hackademix/noscript/issues/359 https://github.com/uBlockOrigin/uBlock-issues/discussions/29... https://github.com/brave/brave-browser/issues/41173#issuecom...
I'm not sure how you can interpret forking open source codebases as a "shady" behavior (it's one of the most important reasons to use open source in the first place), but in this case there is a high demand for said extensions and Brave has provided the only way to continue doing so on a Chromium rendering engine.
(I am one of the devs who worked on the spec for this feature)
- Open source has the best kind of coordination. If there's a real use-case for two things to work together, you or someone else can implement it and share it without anyone's permission. Meanwhile in proprietary land, people sometimes build things that nobody wanted, and also leave out features with high demand. Proprietary optimizes for the profit of some individuals; open source optimizes for maximum utility.
Thus far, open source has optimized for maximum utility for individuals who can write code... but AI may be changing that soon enough.
- As someone who's been building an adblocker for the last 6 years: yes, there's plenty of proof in the devtools console on more websites than you'd think.
Fingerprintjs [1] is a well known one that gets a lot of use. And if you check EasyPrivacy, you'll see the rules to block it [2] have been in place for a long time.
[1] https://github.com/fingerprintjs/fingerprintjs [2] https://github.com/easylist/easylist/blob/132813613d04b7228c...
- 5 points
- As I see it, Brave is the only Chromium-based browser with a competitive Mv2-deprecation-resistant adblocker. If adblocking is important to you - and it is, to many people - then Brave literally is the only one worth considering. Not to mention it is open source, unlike most of the others.
(I work on Brave's adblocker, and FWIW the folks who work for Brave are very open about their affiliation when commenting about it online)
- uBlock Origin is available from brave://settings/extensions/v2; see https://brave.com/blog/brave-shields-manifest-v3/
- If you really wanted to know, most of the tests for Brave's adblock engine are at https://github.com/brave/adblock-rust/tree/master/tests
Those are automated unit and integration tests with controlled filter data as inputs. That's the only practically useful kind of test for an adblocker.
- 2 points
- I did actually make a rough proof-of-concept of this! One of my long-term visions is to have it running natively in-browser, and able to automatically fix site issues caused by adblocking whenever they happen.
The PoC is a bit outdated but it's here: https://github.com/brave/cookiemonster/tree/webext
- I've been using Llama models to identify cookie notices on websites, for the purpose of adding filter rules to block them in EasyList Cookie. Otherwise, this is normally done by, essentially, manual volunteer reporting.
Most cookie notices turn out to be pretty similar, HTML/CSS-wise, and then you can grab their `innerText` and filter out false positives with a small LLM. I've found the 3B models have decent performance on this task, given enough prompt engineering. They do fall apart slightly around edge cases like less common languages or combined cookie notice + age restriction banners. 7B has a negligible false-positive rate without much extra cost. Either way these things are really fast and it's amazing to see reports streaming in during a crawl with no human effort required.
Code is at https://github.com/brave/cookiemonster. You can see the prompt at https://github.com/brave/cookiemonster/blob/main/src/text-cl....
- It wouldn't get passed on. Without land value tax, holding real estate is a good enough investment on its own that rent prices can be left artificially inflated. LVT puts pressure on landlords to actually earn back the value of the property to avoid losing money. In practice, that means offering competitive pricing.
This is a solid in-depth explanation, if you're interested: https://www.gameofrent.com/content/can-lvt-be-passed-on-to-t...
- I work on adblocking at Brave.
1. Brave, Vivaldi, and Opera have all announced they'd maintain support for Mv2 past Google's deprecation date [1].
2. Your guess is correct - one of Google's stated motivations is to make the extension review process easier and less error-prone; having a way to opt-out would be counterproductive in that regard. I strongly doubt they'd accept the PR upstream; there is a chance other players could maintain patches to modify Mv3 but the effort of designing and implementing a new spec around the Mv3 spec and convincing extensions to maintain yet another platform means this is unlikely to happen in practice. Keeping Mv2 around is a more reasonable approach (and one that is compatible with Firefox, as well).
[1] https://www.zdnet.com/article/opera-brave-vivaldi-to-ignore-...