edit: “isn’t this implemented in-browser?” comments: maybe, but it’s to the browser’s implementation. These plugins are reviewable separate from their analogous browser implementation.
Isn’t NoScript redundant if you run UBO in medium mode?
Roughly similar to using Adblock Plus with many filter lists + NoScript with 1st-party scripts/frames automatically trusted. Unlike NoScript however, you can easily point-and-click to block/allow scripts on a per-site basis.
If you go in ublock origin settings, scroll all the way down, you can toggle a setting that disables JS by default. On each site you can whitelist it by clicking ubo and enable JS.
I wasn’t aware of this feature in UBO, but it doesn’t seem to be quite the same. As best I can tell (with a quick test), UBO lets me turn all scripts on or off for a site. I don’t see any sort of granular controls for selecting which domains to load scripts from (and I might just be missing it). For example, I may want to allow first party scripts to run on a site and maybe third party scripts from one or two domains. But, I don’t want scripts from other third party domains to execute. It’s very much a fine grained, least privileged style of script management. It’s a lot more work, as you often have to spend a few minutes sussing out which domains need to be whitelisted to allow a site to reach minimum functionality; but, you are not often caught offguard by a site doing strange things on your system.
If you check “I’m an advanced user” in the settings, then hit the “More” button in the dropdown a few times it’ll show the more advanced interface that lets you choose which third party domains to allow. It doesn’t work quite the same since it blocks both content and scripts per site, but I find it good enough for my usage.
edit: You can technically block just scripts per 3rd party site, but it involves manually editing the content type for your rules in the settings. It’s not part of the main interface, so I never bother using it.
Yeah, sorry… My head was in 1000 different places when I wrote that. Sloppy of me.
Overall I agree with the general statement that less code is better, except perhaps in this case it is not.
What I had been trying to say is in-browser privacy implementations are liable to be incomplete from the perspective of privacy minded users because the software publishers, say, Mozilla, are competing for market share of installed, default browsers. One way they maintain market share is by having the fastest and most accurate page renders for the widest base of use cases. To do this requires, in part, some cooperation from website developers whose vested interest in part is in driving ad serves.
Therefore, it’s in the browser publishers’ interest to implement enough privacy and blocking features to effectively stop malware and common nuisances, but not completely cripple ad blocking since ads are a key part of web site operators’ revenue. They’re trying not to alienate that part of the web economy such that their browser suddenly starts hitting those “please turn off you ad blocker or select another browser” paywalls.
Mozilla pretty much said this was the case a few years ago when they opted not to turn on the privacy features by default in new installs because the advertisers threatened to start hobbling websites for Mozilla browsers. I don’t know that the situation has really changed much since then.
Anyway, my point was that the in-browser privacy features are a good start and should be enabled, but also that they amount to little more than a fig leaf over the question of effectively blocking ads. Loading the adblockjng extensions accomplishes a few things for the user. First, the extensions grant a more complete, uncompromised blocking experience for the user. Second, it grants the user finer-grained control over the whole web experience, letting the user decide what ads and cross-site data sharing occurs. Finally, the code is independent of the browser and so it doesn’t alienate the site owners from the browser publisher.
For Mozilla, it shifts the responsibility of incomplete page loads and breakage onto the user, which in my opinion is where we want it.
That’s why I’m advocating for doing both in this case: because the browser publishers have a vested interest to remain relevant in an economy that wants you to see the ads, and will do everything it can to make you click them. The best defense against for the user that is a multilayered approach.
Finally, I do want to acknowledge that I’m using the terms “privacy” and “ad blocking” too loosely here since they are separate, distinctly nuanced topics. The extensions help more in the ad blocking space than the privacy space, but in what I wrote I think its fair to say that overall the extensions do improve outcomes where the two spaces intersect.
Wow, you are really confused. The argument about the functionality being already implemented by Firefox was about https everywhere. This has nothing to do with adblocking and it does break some sites (the one still not using https) but you can still access them with a click.
UBlock Origin
NoScript
HTTPSEverywhere
edit: “isn’t this implemented in-browser?” comments: maybe, but it’s to the browser’s implementation. These plugins are reviewable separate from their analogous browser implementation.
Belt & suspenders approach. Camp on it.
“Sponsor Block” is a game changer as well
I thought HTTPS everywhere was baked into browsers now and didn’t need to be installed anymore? Is that not correct?
Yes i think firefox will do it if configured correctly
Yeah HTTPS-everwhere was important 10+ years ago, but now the main browsers all do this by default.
Isn’t NoScript redundant if you run UBO in medium mode?
If you go in ublock origin settings, scroll all the way down, you can toggle a setting that disables JS by default. On each site you can whitelist it by clicking ubo and enable JS.
I wasn’t aware of this feature in UBO, but it doesn’t seem to be quite the same. As best I can tell (with a quick test), UBO lets me turn all scripts on or off for a site. I don’t see any sort of granular controls for selecting which domains to load scripts from (and I might just be missing it). For example, I may want to allow first party scripts to run on a site and maybe third party scripts from one or two domains. But, I don’t want scripts from other third party domains to execute. It’s very much a fine grained, least privileged style of script management. It’s a lot more work, as you often have to spend a few minutes sussing out which domains need to be whitelisted to allow a site to reach minimum functionality; but, you are not often caught offguard by a site doing strange things on your system.
If you check “I’m an advanced user” in the settings, then hit the “More” button in the dropdown a few times it’ll show the more advanced interface that lets you choose which third party domains to allow. It doesn’t work quite the same since it blocks both content and scripts per site, but I find it good enough for my usage.
edit: You can technically block just scripts per 3rd party site, but it involves manually editing the content type for your rules in the settings. It’s not part of the main interface, so I never bother using it.
Ah ok. I might give that a whirl then.
I don’t understand your edit, how is more things doing the same thing better? It adds complexity, attack surface while taking resources.
Yeah, sorry… My head was in 1000 different places when I wrote that. Sloppy of me.
Overall I agree with the general statement that less code is better, except perhaps in this case it is not.
What I had been trying to say is in-browser privacy implementations are liable to be incomplete from the perspective of privacy minded users because the software publishers, say, Mozilla, are competing for market share of installed, default browsers. One way they maintain market share is by having the fastest and most accurate page renders for the widest base of use cases. To do this requires, in part, some cooperation from website developers whose vested interest in part is in driving ad serves.
Therefore, it’s in the browser publishers’ interest to implement enough privacy and blocking features to effectively stop malware and common nuisances, but not completely cripple ad blocking since ads are a key part of web site operators’ revenue. They’re trying not to alienate that part of the web economy such that their browser suddenly starts hitting those “please turn off you ad blocker or select another browser” paywalls.
Mozilla pretty much said this was the case a few years ago when they opted not to turn on the privacy features by default in new installs because the advertisers threatened to start hobbling websites for Mozilla browsers. I don’t know that the situation has really changed much since then.
Anyway, my point was that the in-browser privacy features are a good start and should be enabled, but also that they amount to little more than a fig leaf over the question of effectively blocking ads. Loading the adblockjng extensions accomplishes a few things for the user. First, the extensions grant a more complete, uncompromised blocking experience for the user. Second, it grants the user finer-grained control over the whole web experience, letting the user decide what ads and cross-site data sharing occurs. Finally, the code is independent of the browser and so it doesn’t alienate the site owners from the browser publisher.
For Mozilla, it shifts the responsibility of incomplete page loads and breakage onto the user, which in my opinion is where we want it.
That’s why I’m advocating for doing both in this case: because the browser publishers have a vested interest to remain relevant in an economy that wants you to see the ads, and will do everything it can to make you click them. The best defense against for the user that is a multilayered approach.
Finally, I do want to acknowledge that I’m using the terms “privacy” and “ad blocking” too loosely here since they are separate, distinctly nuanced topics. The extensions help more in the ad blocking space than the privacy space, but in what I wrote I think its fair to say that overall the extensions do improve outcomes where the two spaces intersect.
Anyway, nice chat. Thanks for keeping me honest
Wow, you are really confused. The argument about the functionality being already implemented by Firefox was about https everywhere. This has nothing to do with adblocking and it does break some sites (the one still not using https) but you can still access them with a click.
Ah, that makes sense. Fair enough, I guess Incan disable that plugin now.