Hi Alexei,
Thanks for raising this. As I’m sure you noticed,
we are supportive in general of implementing a way to extract and redirect to URL-encoded components in line with the issue you opened.
We did make the decision to focus on this after June, rather than before the deprecation. We made
many improvements to Declarative Net Request over the last few months - but ultimately not every feature request could be completed before June. As you shared there are extensions that would use this functionality, but significantly fewer than would benefit from some of the other DNR changes we worked on and made a higher priority.
Looking at the request, I think there is a clear path for handling the simple cases, for example with
example.com/?redirect=test.example.com. While we might not be able to support every variation, I am hopeful we can find ways to support some of the trickier cases where the URL has been added to the query parameter in a more encoded form. We’ll definitely think more about that ourselves and are open to brainstorming with you in the community group.
There are workarounds for the general case of extracting URL parameters, such as with RegEx filters and using content scripts. I know you have also pointed out limitations with those in various things you’ve written in the past, which is why we want to solve this at a platform level - but it does reduce the number of cases where developers are likely to hit this limitation.
We are very glad extensions like Privacy Badger exist and if you’d like to reach out to chat more about how to migrate specific features we’d be very open to that.