It's a bit disingenuous to refer to this as an "exploit" all throughout the article. It's a feature, and an intended one at that. It's offering whitelist maintainers more power over their filters. You can disagree with its inclusion in the spec (as I do), but you should make an argument on that premise instead.
Calling it an exploit is no different than claiming .exe files are exploits because they allow arbitrary code to run. Or that browser extensions are exploits because they too can manipulate the page.
It’s rightly referred to as a vulnerability; the term exploit is used to describe a realistic scenario that is enabled by the vulnerable code.
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).
>The problem is that you can’t necessarily trust filter maintainers to be completely honest.
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.
> the author is using a bad faith argument by describing a feature they dislike as an exploit
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.
I don't believe it's been edited (or I haven't noticed such an edit). However on a subsequent re-read, I can see the author's usage of the term "exploit" is more specific to his example below (the Google Maps attack demo).
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.
User expectation is important. You don't generally have to put warnings on knives that they may cut you, but if you made a coffee mug that sliced peoples lips up you would get in trouble.
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.
No, and if someone could use that extension to run arbitrary code in my browser I'd consider that an exploit, even if "Added rewrite option" is in the changelog.
Calling it an exploit is no different than claiming .exe files are exploits because they allow arbitrary code to run. Or that browser extensions are exploits because they too can manipulate the page.