The problem is that you can’t necessarily trust filter maintainers to be completely honest. Users don’t regularly audit the thousands of rules in their filter lists, so a bad or compromised filter could easily introduce a malicious filter in an update. The $rewrite rule lets a filter change what code is being loaded by a webpage (under certain fairly realistic situations).
I agree with that, and it's not a strong security model. But my original point is that the author is using a bad faith argument by describing a feature they dislike as an exploit. It's in spec for what the original authors intended. Just like running an executable program is potentially risky, but a design of the system.
I read the article and perhaps it's been edited since you commented, but the author states in the introduction that there is a security vulnerability in a feature and provides an exploit. That to me is quite different from calling the feature itself an exploit.
> It's in spec for what the original authors intended. Just like running an executable program is potentially risky, but a design of the system.
While it's true that it is in spec, I see a big difference in terms of how users experience this situation compared to running an executable program. I see this as more analogous to new feature introduced in an executable format that offers a different security guarantee to what users are already comfortable with. I don't see pointing this out as being in bad faith.
While I'd still argue it's "working as intended" (for better or worse), he is at least calling this specific demonstration an exploit rather than the feature as a whole. So I'll step back from that position, at least part way.
Thank you for the clarification on that point.
As a developer, I expect that browser plugins can execute code in some context (though I think general users may not even expect that); but I don't generally expect that plugins will execute code from some arbitrary 3rd party source.