2 ms·

I didn't review the millions of lines of vim code either, yet notepad.exe lets me use it to edit passwords.txt and banking_details.txt just fine.

by MikeUt 6y ago

Arnt 6y ago
There are two differences. 1. NPM is being actively exploited and IMHO remarkably often; some of the third parties that are blocked by this policy are known to be malevolent. 2. I'm afraid my familiarity with Windows is somewhat limited. As far as I know Notepad has no responsibility for carrying out any sort of access control. That it carries out no access control is somewhat irrelevant if it is not intended to do so in the first place.
- candiodari 6y ago
  But you can firewall (in 10 different ways) notepad.exe. You control what notepad has access to. You can access anything notepad.exe can bypassing notepad.exe. You cannot effectively firewall your browser, because you don't control the backend. You cannot bypass the backend of a piece of cloud software. This is a generic problem with cloud software. Any cloud software has access to your data AND YOU DO NOT. To a certain extent it even has access to your data in other apps (e.g. getting your mail address). It's a way to (currently usually partially) transfer ownership of everything you make with software, and your own data from the user to the creator of the software. This obviously an extremely negative development in the long run, but people seem quite keen on just accepting it ...
- MikeUt 6y ago
  > That it carries out no access control is somewhat irrelevant if it is not intended to do so in the first place. That's circular logic - Google's access control is OK because Google intended to do it? Do the users get a say in whether these APIs are intended to do access control?
  - Arnt 6y ago
    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.

I didn't review the millions of lines of vim code either, yet notepad.exe lets me use it to edit passwords.txt and banking_details.txt just fine.

by MikeUt 6y ago

I didn't review the millions of lines of vim code either, yet notepad.exe lets me use it to edit passwords.txt and banking_details.txt just fine.

Arnt 6y ago

There are two differences. 1. NPM is being actively exploited and IMHO remarkably often; some of the third parties that are blocked by this policy are known to be malevolent. 2. I'm afraid my familiarity with Windows is somewhat limited. As far as I know Notepad has no responsibility for carrying out any sort of access control. That it carries out no access control is somewhat irrelevant if it is not intended to do so in the first place.

candiodari 6y ago
But you can firewall (in 10 different ways) notepad.exe. You control what notepad has access to. You can access anything notepad.exe can bypassing notepad.exe. You cannot effectively firewall your browser, because you don't control the backend. You cannot bypass the backend of a piece of cloud software. This is a generic problem with cloud software. Any cloud software has access to your data AND YOU DO NOT. To a certain extent it even has access to your data in other apps (e.g. getting your mail address). It's a way to (currently usually partially) transfer ownership of everything you make with software, and your own data from the user to the creator of the software. This obviously an extremely negative development in the long run, but people seem quite keen on just accepting it ...
MikeUt 6y ago
> That it carries out no access control is somewhat irrelevant if it is not intended to do so in the first place. That's circular logic - Google's access control is OK because Google intended to do it? Do the users get a say in whether these APIs are intended to do access control?
- Arnt 6y ago
  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.