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 networking sites deliberately to slow them down so I'll that I'll be less likely to impulsively refresh them.
I continue to believe that the manifest changes aren't written with the perspective of enabling creative, unseen uses of the API in the future. They're written from the perspective of, "let's decide up-front what extensions we want, and enable specifically them."
The feedback people have given on this is extremely broad, and is mostly ignored by this post. It's disappointing to see a response that at least somewhat suggests the Chrome team is dead set on shipping this, and is only willing to bend so far as it takes for them to enable the most popular adblockers that exist today. If it took that much feedback to get Chrome to even slightly tweak the design, then what possible feedback can people give going forward to make anything more significant happen?
Tampermonkey being limited is huge for us. I used to actually implement a chrome extension for work to automate interaction with some partner sites, but tampermonkey key is so much easier to manage, test on, and update for. I'm dreading having to go back to extensions, especially since all of them will have a review process so there's yet another hurdle.
>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?
Do you mean through the dev tools? That would require me to leave the dev tools open while I browsed. I would also need to manually turn it on, which defeats the purpose of it being an automatic thing that interrupts an instinctual behavior.
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."
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 networking sites deliberately to slow them down so I'll that I'll be less likely to impulsively refresh them.
I continue to believe that the manifest changes aren't written with the perspective of enabling creative, unseen uses of the API in the future. They're written from the perspective of, "let's decide up-front what extensions we want, and enable specifically them."
The feedback people have given on this is extremely broad, and is mostly ignored by this post. It's disappointing to see a response that at least somewhat suggests the Chrome team is dead set on shipping this, and is only willing to bend so far as it takes for them to enable the most popular adblockers that exist today. If it took that much feedback to get Chrome to even slightly tweak the design, then what possible feedback can people give going forward to make anything more significant happen?