Hacker News new | past | comments | ask | show | jobs | submit login

> Well it all depends what the requests are, doesn’t it.

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.






>like that it considers requests to subdomains third-party)

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.


Neither xhr nor subdomains sound like valid features/bugs. Just because they don’t agree with changes you want doesn’t mean it’s “abandoned”.

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.


I don't think our discussion can come to any compromise. You seem to believe that not doing anything is a good thing, and the API is already ideal. I have a different opinion. Well, it's okay to have different opinions.

> You seem to believe that not doing anything is a good thing, and the API is already ideal

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".




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: