I think Apple took a step in this direction when they started forcing you to navigate to Security & Privacy to enable the modal the first time when launching an untrusted app.

They could probably add an opt-out step two for consumer level use where that step is also required for all root permissions requests. I would add a fast blink of the webcam light to prove trusted modal is open.

Currently it is incredibly clunky (they should put a notification at the top of the settings like for software updates), but you have some indication what app is triggering it and the dialogue could be hidden until it is time to review updates. Showing all entitlements and privacy settings should also be required any time a root password is requested with changes being noted as unusual, including changes in developer accounts.

Damn, that really puts things into perspective. Granted, attached modals presuppose there's a window to attach to. But I think that would probably be true 9 times out of 10.

Even if not, attaching to the menu bar (with some “chrome” that goes above the menu bar itself, which normal windows don't (can't?) do) would be superior to attaching to nothing.

This is pretty straightforward for a malicious application to simulate.

I think parent commenter was solving the attack vector of a website showing a password modal to look like it just happens to float over the browser. By conditioning users that a password modal is always attached to the gui of the application requesting it, the hope is that a password modal on a browser window would raise suspicion with the user.

I think that was the idea, at least.