They've been available natively on Nightly with some basic UI support since they were first implemented a decade ago. Some other pre-release builds have them too but it's been too long and I cannot remember which ones did or didn't.
Respectfully to the American "this isn't that big a deal crowd": you're looking at it from the perspective that this is a commonplace occurrence in your country.
IANAL but I have filed privacy complaints in the past at both the federal and provincial level. For the last 26 years in Canada it has been illegal for personal information to be bought and sold on a whim; the person to whom the information applies is considered to be the owner and is entitled to be in control of how their information is used, and may revoke consent.
You have an entire country where institutions operate under the expectation that personally identifiable information isn't easily available like this (sans the usual data breaches). Those institutions are probably less prepared to deal with this data floating around everywhere than in a society where it is essentially a free-for-all.
I mean, it's not really optional for Canadians _not_ to sign up for the list. It's the official list of electors. If you're a citizen, you're going to end up on the voter list one way or another.
I don't know whether is still does this, but 8-9 years ago I discovered that Acrobat overwrites the COM registry entries for Microsoft Active Accessibility (oleacc.dll) such that any application attempting to instantiate MSAA gets the Adobe DLL instead of the system DLL. This actually broke the stuff I was working on and had to override it in my app manifest to forcibly use the system version.
I inquired about it and got some BS about how they absolutely _had_ to do this to intercept MSAA instantiations across the system, when in reality they were using a global solution to solve a local problem.
I too learned this the hard way, via a supposedly concurrent priority queue that did quadratic-time work while holding a lock over the entire thing. I was told that "premature optimization is the root of all evil."
Sorry, folks, but that's just an excuse to make dumb choices. Premature _micro_optimization is the root of all evil.
EDIT: It was great training for when I started working on browser performance, though!
Agreed. Nitpicking about indirection is definitely a "premature micro-optimization is the root of all evil" moment.
When I worked on Firefox, we eventually had to remove a bunch of indirection (the interested can actually search bugzilla.mozilla.org for deCOMtamination for some instances of this), but that project wasn't a thing until there was clear evidence that there were problems with virtual function calls on hot paths.
This is a terrible idea! _Maybe_, _maybe_ using only the documented APIs with only the documented parameters.
Unfortunately it makes too many false assumptions about interoperability between Win32 and the underlying native API that aren't true.
For example (and the Go runtime does this, much to my chagrin), querying the OS version via the native API always gives you "accurate" version information without needing to link a manifest into your application. Unfortunately that lack of manifest will still cause many Win32 APIs above the native layer to drop into a compatibility mode, creating a fundamental inconsistency between what the application thinks the OS capabilities are versus which Win32 subsystem behaviours the OS thinks it should be offering.
Similarly, I've seen this in enterprise IAM software, but again as data, not as code.
Imagine a very large company that has a heterogeneous setup: say it has plain LDAP for *nix machines and AD for Windows. The IAM stuff has connectors for both, and encoding the org chart into that product enables it to synchronize that structure into both systems.