* 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 this part of the browser.
* It's harder to work with this API than a JavaScript code-base you control.
* Chrome seems a bit better here but for Safari the documentation is pretty poor.
* 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.
That's only a few points from my personal experience but I discussed multiple times with developers of other privacy-enhancing extensions/apps and we shared similar feelings.
> 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 this part of the browser.
I think this is especially true. It is somewhat similar to many other Google products like Maps and Translate. They start as a good free product, but as soon as they gain enough traction the rules change.
I think once this declarative Api is the standard for ad blockers in browsers Google will start exercising its control over it for its own benefit.
This is their long game. To me all the push Google did with https, and certificate pinning etc makes much more sense. I was wondering why they were pushing it so hard.
I mean after they essentially blocked ways to use proxy to filter the content, next logical step is to restrict API.
If you want to proxy your HTTPS traffic you add a local CA, and Chrome does not apply certificate pinning. Pinning is only for certs that chain back to the default CAs, specifically so people who need to proxy can do so.
(Disclosure: I work for Google, though not on Chrome)
Sure, but then you're still at the mercy of the browser.
The API change is totally unnecessary, yet is happening despite many protests.
The concern is that it was performance and privacy issue, which looks like a total BS (even according to the link we are discussing).
The extensions are installed by the user, so what not let them decide what to do with their browser? If it's really a concern, I don't think anyone would oppose if google would educate user what API given extension is using.
> 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.
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.
* 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 this part of the browser.
* It's harder to work with this API than a JavaScript code-base you control.
* Chrome seems a bit better here but for Safari the documentation is pretty poor.
* 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.
That's only a few points from my personal experience but I discussed multiple times with developers of other privacy-enhancing extensions/apps and we shared similar feelings.