101–110 of 126 posts
So Ghostery benchmarks and is the fastest? Fine. But Ghostery does not belong in that test at all. Of course it can be faster. It misses a lot of the most important features! Like custom lists. Totally an ad.
Enjoy the good, ignore the bad.
They should test on average hardware and not on the top one. Take a 2013 year Celeron or Atom with 2 Gb of RAM and HDD and test on it.
Regarding privacy, I think the code that blocks network requests could run in an isolated environment so that it cannot send the information about requests outside.
Earlier quoted context omitted.
Speaking as a user (and early developer) of Safari's content blockers; I have almost never run into an issue with them. What kind of development do you fear will be stifled by Apple and Google not having incentives to improve the blocking (which I find somewhat strange in the former case, anyways)?
What I'm afraid of is the following: * The blocking engine operated by either Safari or Chrome is a black-box and independent devs will have a harder time understanding it, tweaking it, improving it, debugging it. * Chrome devs are now playing nicely and get feedback and propose some improvements to the APIs but there is no warranty this will happen again, or that they will invest time/energy in the future improving…
I mean, both engines are open-source, but yeah, I do agree that it would be nice it have this enshrined in a web standard rather than a de-facto one driven by the shins of two large corporations.
> You also don't get feedback regarding the rules which matched on a page and this makes it harder to debug or give nice insights to users.
This seems like an easy tooling problem to fix.
Earlier quoted context omitted.
Speaking as a user (and early developer) of Safari's content blockers; I have almost never run into an issue with them. What kind of development do you fear will be stifled by Apple and Google not having incentives to improve the blocking (which I find somewhat strange in the former case, anyways)?
The difference is categorical. The current web request APIs can delay approval/rejection of any request for an indefinite amount of time to perform arbitrary computation (including IO or talking to other extensions) to decide. It can also be stateful. This doesn't just knock the power of your adblocker down from Type-0 to Type-4 of the chomsky hierarchy, it also limits the inputs it can act on. As an example, if I wa…
I believe this is the reason Safari introduced content blockers. It fits in very well with the traditional computing model on iOS of preventing unbounded, arbitrary computing where possible.
Earlier quoted context omitted.
Scroll to the footer and you'll see that this is Ghostery's website. I wouldn't really call promoting their own product on their own webpage an ad.
A rose by any other name would smell as sweet. Ghostery doesn't want their bias to be obvious to the non-discerning user because it's obviously an attempt to reclaim market share using dirty tactics.
Earlier quoted context omitted.
> On the other hand, the manifest v3 will not prevent extensions from being slow, or doing bad things. Extensions will still be able to use content-scripts, inject arbitrary content in pages or send any private data home. WebRequest listeners will also still be accessible (only not in blocking mode) which can allow any data collection. I can choose to not install extensions that do these things, while using ones that…
I agree with you, and that's why I would like to see this declarative API being an addition to the current WebRequest API. This way there could be extensions using it exclusively and users could decide to pick these if they offer sufficient privacy protection for their taste. On the other hand, you would still have the option of installing more powerful extensions using the dynamic APIs (allowing things which will ne…
> All benchmarks were ran on an X1 Carbon 2016 (i7 U6600 + 16 GB) in Node.js 11.9.0. They should test on average hardware and not on the top one. Take a 2013 year Celeron or Atom with 2 Gb of RAM and HDD and test on it. Regarding privacy, I think the code that blocks network requests could run in an isolated environment so that it cannot send the information about requests outside.
Even things as simple as build times, I've seen vary by 20+%.
Earlier quoted context omitted.
The difference is categorical. The current web request APIs can delay approval/rejection of any request for an indefinite amount of time to perform arbitrary computation (including IO or talking to other extensions) to decide. It can also be stateful. This doesn't just knock the power of your adblocker down from Type-0 to Type-4 of the chomsky hierarchy, it also limits the inputs it can act on. As an example, if I wa…
> The current web request APIs can delay approval/rejection of any request for an indefinite amount of time to perform arbitrary computation (including IO or talking to other extensions) to decide. I believe this is the reason Safari introduced content blockers. It fits in very well with the traditional computing model on iOS of preventing unbounded, arbitrary computing where possible.
And even if we suppose that it is a reasonable policy for a moment, it's still not all that relevant since we're not talking about the apple ecosystem here in the first place.
Worth keeping in mind here is that Ghostery is proprietary, while uBlock is free software. You should never trust proprietary extensions with your data.
There is an argument to be made about motives with free vs non-free software, but open vs closed source is for most people much less important.
Earlier quoted context omitted.
Dynamic rule addition addresses a very small number of complaints with the proposal. Beyond the ability to block requests conditionally based on arbitrary logic (not just a few pre-decided qualifications like request size), one point I want to keep coming back to is that there are actually legitimate reasons why an extension might choose to slow down requests. I use Tampermonkey scripts on a couple of social networki…
>I use Tampermonkey scripts on a couple of social networking sites deliberately to slow them down so I'll that I'll be less likely to impulsively refresh them. Could you use Chrome's simulated network throttling instead?
I don't see an API anywhere that makes network throttling available to extensions, but let's assume Chrome adds one.
In that case, it still lacks granularity -- I only want to slow down some requests on some sites. One thing I've been thinking about doing if I turn this into its own extension is having it respond to your aggregate time on a site. So the more time you spend on a social site, the slower it gets, but if it's been closed for a while it starts to "recharge" and speed up again. In particular I'm thinking about that for sites like Twitter, where I don't mind checking it so much as browsing it.
There's a lot of interesting stuff that's possible with the current API that can't be replicated by just saying, "slow down everything across the board."