5 ms·

So you are telling me that not changing the API in years despite numerous requests is a good thing? Well, I disagree. Regarding https, this change was made in

So you are telling me that not changing the API in years despite numerous requests is a good thing? Well, I disagree. Regarding https, this change was made in 2015.

bobthepanda 7y ago
There's a wide spectrum between "abandoned" and "totally up to date." Not everything is black and white.
stephenr 7y ago
Well it all depends what the requests are, doesn’t it. 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.
- ameshkov 7y ago
  > 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.
  - Nadya 7y ago
    >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.
  - stephenr 7y ago
    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.
    - ameshkov 7y ago
      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.
      - stephenr 7y ago
        > 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".

So you are telling me that not changing the API in years despite numerous requests is a good thing? Well, I disagree. Regarding https, this change was made in 2015.

bobthepanda 7y ago

There's a wide spectrum between "abandoned" and "totally up to date." Not everything is black and white.

stephenr 7y ago

Well it all depends what the requests are, doesn’t it. 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.

ameshkov 7y ago
> 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.
- Nadya 7y ago
  >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.
- stephenr 7y ago
  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.
  - ameshkov 7y ago
    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.
    - stephenr 7y ago
      > 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".