Yes, exactly. The implementation difficulties are why this idea hasn't taken the world by storm yet. Incentives are also not there for app developers to think about programming this way - it's much easier to just request a general permission and then work out the details later.

For the server ID, it really should be based on the public key of the server. A particular service should keep its private key secret, broadcast a public key for talking to it, and then being able to encrypt traffic that the server can decrypt defines a valid connection capability. Then the physical location of the server can change as needed, and you can intersperse layers of DDoS protection and load balancing and caching while being secure in knowing that all the intervening routers do not have access to the actual communication.

▲

saagarjha 2 days ago | parent [-]

Should Google and YouTube share a key? How about Google LLC and Google UK Limited?

	▲	nostrademons 2 days ago \| parent [-]
		No, and both Google and YouTube should be multiple keys. YouTube, for example, should have separate capabilities for watching videos (ideally on a video-by-video basis); autoplaying; viewing metadata; posting comments; uploading videos; viewing playlists; editing playlists; signing up for YouTube Premium; and a number of other operations. That way, somebody who has granted their software agent the capability to play YouTube instructional videos doesn't risk having their credit card charged for YouTube Premium or ruining their reputation by posting questionable spam on everybody else's videos. Setting up the economic incentives to encourage this is a hard problem. Right now, the disincentives to this are: 1) it adds engineering overhead to secure everything behind a different private key 2) it adds PM overhead to determine what the right granularity is and what potential adversarial avenues exist 3) it creates user confusion as they're bombarded with a list of fine-grained permissions 4) it prevents tech companies from cross-selling new features and impedes new feature discovery. There's basically no reason to do it other than protecting the user, and the user probably won't know they've been compromised until long after they start using the service.