Ladybird is natively integrating Brave's adblock engine https://github.com/LadybirdBrowser/ladybird/pull/9587
HN user
antonok
https://antonok.com
[ my public key: https://keybase.io/antonok; my proof: https://keybase.io/antonok/sigs/VR_-POMgFiZfvYQj3ZacA_L0Xg_9prKxELr_U0LpeZw ]
Brave has it on both desktop and mobile https://brave.com/privacy-updates/34-block-page-elements-and...
It should be able to. Waterfox is using roughly the same integration and the maintainer has been seeing reports of YouTube issues, but cannot reproduce it. https://github.com/BrowserWorks/waterfox/issues/4182#issueco...
OpenCode has been great in my experience. I still get the best results using it with Anthropic's models, but some of the open weights ones are catching up (GLM 5 works reasonably well for me).
I had the same thought too. It's probably not too difficult to fine-tune a small model for it using the "introduce a random mutation and describe the issue" workflow from TFA
rillian was also instrumental in helping to integrate Rust into Chromium at Brave. I worked with him for a few years; since getting to know him, I started noticing his handle in the contributors list across a surprisingly diverse range of other open source projects. RIP, Ralph.
fwiw, LEDs with higher CRI will generally be less power efficient, so the premium category has a 3-way tradeoff between brightness, power, and color quality. It's common for high efficiency LED lightbulbs to be much worse at illuminating red objects.
You'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
I'm using a non-standard port (above 10000). Otherwise, nothing special about my configuration. Perhaps 51820 is blocked?
It is admittedly quite slow/intermittent though; I wouldn't be surprised if that's the reason it didn't look like it was working for you.
Funnily enough, I'm on a British Airways flight right this moment. I'm only using a basic Wireguard tunnel after enabling the free messaging plan. I get the sense they didn't design the firewall to block everything comprehensively.
You could also look into running mobile Linux on top of libhybris - it's a proprietary compatibility layer, but some people use it to get support for mobile Linux runtimes on more recent devices.
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...
There is an Aggressive setting for Brave Shields, which you can set either per-site in the Shields menu from the URL bar, or globally in brave://settings/shields - that should take care of SERP ads and other first-party placements.
Brave's adblocker supports the standard `$font` resource type modifier on adblock rules as well.
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.
FWIW, there is an alternative to OCA film that's slightly easier to apply in small quantities without specialized hardware - it's called LOCA glue (i.e. Liquid OCA).
I'd definitely recommend that if you're just assembling less than, say, 10 screens.
You probably wouldn't want to run this in real-time on every site as it'll significantly increase the load on your browser, but as long as it's possible to generate adblock filter rules, the fixes can scale to a pretty large audience.
Ha, I'm not sure the EU is prepared to handle the deluge of petitions that would ensue.
On a more serious note, this must be the first time we can quantitatively measure the impact of cookie consent legislation across the web, so maybe there's something to be explored there.
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...