It's not circular. You may classify internet-accessible APIs into three top-level-classes: 1. Ones that perform no authentication. 2. Ones that perform authen

It's not circular. You may classify internet-accessible APIs into three top-level-classes: 1. Ones that perform no authentication. 2. Ones that perform authentication and place some trust in the client software (for example, the client software would be able to copy the user's private data without the user noticing). 3. Ones that perform authentication and place no trust in the client software. IMO, all three are reasonable, depending on purpose. The APIs in question are in the middle group, and AFAICT couldn't easily be redesigned to fit the third group. And trusting client software that includes an undefined set of NPM packages is unwise, or worse than unwise. My logic isn't circular. I am simply saying that restricting the client software is reasonable because the for these APIs, the client software is in a position to betray the user's trust. There is an effective difference for these APIs between trusting the client software and the server/user trusting each other.