Regarding https, this change was made in 2015.
Regarding https, this change was made in 2015.
I’m sure some have requested the ability to run javascript, that doesn’t mean it’s a good idea to add that to the api.
Oh, there are all sorts of them.
From simple feature requests (like being able to distinguish fetch/xmlhttprequest) and bug reports (like that it considers requests to subdomains third-party) to something more complicated.
The problem is that regardless of what's requested/reported, there is no reaction.
> I’m sure some have requested the ability to run javascript, that doesn’t mean it’s a good idea to add that to the api.
Desktop Safari allows extensions to run javascript, why would anyone want to make it a part of the content blocking API.
As it should. Sometimes subdomains are third party. If I whitelist example.org I do not want any subdomains to be whitelisted without be explicitely whitelisting *.example.org as a wildcard or any specific subdomains.
Proof of concept: I constantly host what I could consider 3rd party resources on subdomains for clients. eg: billing.example.com where billing. isn't owned or operated by example.com and could be running who knows what in terms of Javascript and Ads that I may or may not trust without whitelisting billing.example.com. The most common of these are specific marketing/tracking forms that they wish to run through some third party marketing agency and not our in-house tracking systems.
As for why someone would request JS - you’re the one who suggested chrome/ff blockers are “more advanced”. And yet here we are on a thread about arbitrary code execution.
Not really. I've submitted a request for an enhancement myself (ability to auto-redirect to the canonical URL - to avoid the bullshit of AMP pages) but what you've suggested just don't seem like worthwhile or positive changes IMO.
My argument wasn't "zero change is good" my argument is that it doesn't need much change and a stable API is hardly "abandonment".