uBlock Origin 1.20

Probably because of lack of usage of Safari. It was covered in some circles: https://adguard.com/en/blog/safari-adblock-extensions.html

>No you can't, at least not in the general case. You can trust Mozilla because it's Mozilla, but ultimately that's an "argument from authority".

I'm not saying absolute trust, I'm saying I trust them to write a better polyfill for extensions than I will. An argument from authority is okay when the alternative is an "argument from ignorance". I know I don't know the details, and I'm trusting someone who literally writes the runtime to know it better than me.

>Perhaps, but unless the code you are writing is "safety-critical", those "low chances" are outweighed by the fact that a malicious actor can do far more damage than some bug you introduced. >Also, you have to multiply those low chances with the large amount of micro-dependencies that you might bring in through this attitude.

I'm genuinely curious about this, because from my point of view the number of times that I've encountered a malicious actor is extremely small and is often dealt with within days if not hours. The number of times that i've encountered my own vulnerable code is much more common. And with non-malicious bugs/vulnerabilities the number is similar. It could be just because I find my own bugs easier, but I really think there is something to relying and trusting that the community is going to be able to do something better, faster, and more correctly than I will be able to. Add on the npm audit system which is constantly scanning and notifying about known vulnerable dependencies means I'll be able to find and solve bugs and vulnerabilities much faster than if I had written even most of it myself.

I'd love to see some actual studies done that aren't just relying on anecdotes to see how things really shake out, but I'm not sure how that would even work as there are so many other confounding factors here that make it really hard to make a hard rule about these things (there is a lot of garbage code on the internet and across most package managers, any study would need to separate the "nobody should ever use this" from the "looks good at first glance" code, and at that point you're just making an automated code reviewer...)

>This is a slippery slope argument. I think there's a distinction to be drawn here.

I completely agree, but often drawing those distinctions is arbitrary. You may draw it at the runtime, I tend not to because a runtime (or the tools that make the runtime, etc...) often have much more ability to cause problems than any runtime library does. Counting "number of dependencies" is extremely hard, because like I said cpython does have quite a lot of dependencies, it just depends on where you draw the line. cpython's compilation depends on quite a lot of smaller tools, and the compilers they support and use depend on even more. As you get further down the stack things slow down and are often vetted much more, but that itself doesn't mean much as the "payoff" for a malicious actor to get into it is often equally greater.

And even if you do draw the line at the runtime or compiler, does that mean that the JS dependencies in my package.json that are dedicated to compilation and building don't count toward your numbers? And if you don't count the transitive dependencies for something like cpython, then it seems disingenuous to include them in your statements about how a node package pulls in thousands of dependencies. And if you draw the line at some dependencies being "okay" and others not based on number of authors, dependencies, the amount of vetting, and more, well you're doing exactly what I was advocating for above!

>I put in the "Often" just to make it sound less dogmatic.

That is fair, and I did remove it from the quote. But I started this whole thing because you didn't describe the reasoning behind why you felt that way, and without the why it is literally just dogmatism.

And to be honest I still don't feel you've given a great answer for it besides the idea that as the number of some dependencies goes up the risk of a malicious actor goes up. Which I don't necessarily disagree with! I guess I just draw the line at a different spot. For me the risk of a malicious actor is miniscule compared to the risk of not completing the project from having to write so much code to avoid dependencies, writing bugs in domains that I don't understand, or copying code into my codebase that I don't fully understand breaking the dependency link that I can use to do automated scanning of. Not in every project, but in most.

Note DNS ad blocking is a very limited subset of what browser-level blockers support. Better than nothing but certainly not a replacement.

There used to be a rich history of one-man products maintained selflessly by their creators, even up until the early 2010's. Entrepreneurship and business assholes destroyed that -- we gave this up when we made tech so easy to use that every brother and their mother got on board. Now tech is too big, with too much money, that it cannot help but attract sharks that buy up these sorts of things and then destroy them

Tech should just be for tech people! Mothers and brothers be damed!

I get the frustration, but shouldn’t we be working towards models that allow for better compensation for creators rather than ... well I’m not exactly sure what you’re advocating for here ...