[jmcdiesel]

Isn't any "vulnerability" in a JS framework a vulnerability in the browser's own handling of securing it? Like, there is nothing angular is doing that someone else couldn't do, intentionally, to create said issue, right? Wouldn't the correct handling of this to be to secure the damned interpreter thats running the code to prevent it from having the effect they are trying to mitigate?

This feels like a lazy shifting of blame

[AgentME]

Angular evals text stored in the DOM. If you alone are in control of the DOM (like in a normal webpage), there's no issue. If someone else is in control of the DOM (you're running Angular in a higher-privileged extension running on a random webpage's DOM), then they can put code into the DOM which then gets picked up by Angular and executed within the extension with the extension's full permissions. This isn't an issue inherent to the language or browser at all. This is an issue just comes from that Angular 1.x is designed for use-cases where the DOM is trusted, and that's not the case for browser extensions.

[jmcdiesel]

But thats not special to angular... right? You can write that in vanilla javascript just the same - the issue is that the script running in the extension is given the ability to do that. They dont seem to be blocking a feature in javascript, they seem to be blocking a lib that uses it. Angular can't do ANYTHING that any other bit of javascript can't do in the same context.

Angular is just JS, its not special JS, its just JS. If angular can do something, it can be done without angular so blocking angular does nothing to prevent the vulnerability.

[AgentME]

Eval has legitimate uses, and there's plenty of ways that extensions can be insecure or malicious without using eval.

Firefox's Addons Marketplace reviews extensions and rejects ones that are malicious or insecure.

The issue is not that Angular uses an inherent insecure feature. The issue is that Angular does insecure things: it lets a webpage run any code with the extension's privileges. If the extension has privileges to your email domain, then the webpage can abuse the extension's privileges to harvest your email. An extension that let your email be harvested would get rejected regardless of whether it used eval or not. (For example, a malicious extension could be made which doesn't use eval and is just a couple hard-coded lines to make privileged AJAX connections to gmail.com. There's no technical features that the extension is using that shouldn't be available.)