This is a really cool idea. I love interface disconnected from APIs. We have so many annoyances these days because applications can't be programmatically controlled. Honestly, I'd like to see legislation saying all application functionality needs to have APIs.
I think legislation demanding most tools have an API would be a good thing. Not 'tho shalt expose a REST endpoint'. But instead something like 'every operation a user can do with this tool, they also need to be able to trigger with an interface that is programable, and that interface needs to be documented'.
Saying 'our programable interface is the gui, use autohotkey' is fine, as long as you properly document all click regions.
This would be a massive productivity boost to anyone using such tools. It would also be great for disabled people.
I would not like to have to concern myself with exposing government-compliant APIs when coding any arbitrary tool...the free market can reward good development.
No way, especially because all the people taking most market-business-related decisions (eg which software to buy) are not tech-oriented. If we had more power on these decisions, that would mean that development, and even advertising of products, would be closer to what the parent comment suggest. But alas.
Markets cannot regulate nuanced behavior like this. Microsoft is a trivial example of anti-user practices and generally garbage design nonetheless being adopted due to their tremendous efforts of corporate propaganda and scaremongering the decision makers about their products.
This is true, but the abuse would still be possible today if someone is reverse engineering software or talking to servers where everything is over APIs anyway. I'm talking about local interface decoupled with a local API from implementation. The problem today is that programmers can't compose or build software on top of other software they have.
> I'm talking about local interface decoupled with a local API from implementation.
To expose this "local API" usefully, you must either:
1. Share memory with other processes (new attack vector), or
2. Listen on some kind of network or native socket for messages and authn+authz the commands that come through it based on some security protocol (new attack vector).
The value proposition of an API is to allow control and data flow between an application and some external entity. It seems to me that it has security implications by definition.
