But if it's a LAN API, how exactly will the manufacturer harvest your usage information to sell to third parties? How will they get that sweet, sweet, post-sale monetization?
I know this is a joke, but to just entertain it for a second, if they truly must have telemetry, then why not just have the device submit it anyway?
Local API for control, then submit telemetry via the cloud-version of the API they use for the app.
The obvious answer why not is: it enables people like me to just block the telemetry uploads.
But they can't have it both ways then, they can't make inefficient cloud-based control mechanisms, and then complain when people (ab)use them, because the truth is that that will not stop no matter how many cease and desists they send.
Or the fact that many of the major "security bad press" or "S in IoT stands for security" stories are because such interfaces were made but not properly secured. (see bosch story)
Authentication is something that does need to be solved, that's true, but the device is authenticating to the cloud already, I can promise you any bad implementations that would have happened in a local API is currently in the authentication against the cloud-based management solution instead, it's just less obvious.
Local API for control, then submit telemetry via the cloud-version of the API they use for the app.
The obvious answer why not is: it enables people like me to just block the telemetry uploads.
But they can't have it both ways then, they can't make inefficient cloud-based control mechanisms, and then complain when people (ab)use them, because the truth is that that will not stop no matter how many cease and desists they send.