Hacker News new | past | comments | ask | show | jobs | submit login

This distinction is only useful if additional conditions are satisfied:

The user must not be asked to enter that password repeatedly to do everyday tasks, otherwise it is easy to trick them into entering the password into a malicious input field.

More important, the user must not be expected to routinely waive all protection for required tasks. For example, the user is often expected when installing software on a computer to give administrator privileges to an installer script which comes from an untrusted source. The user is expected to "make sure the source is trusted". This does nothing but put the blame on the user, who cannot do that in a meaningful way at all, yet is expected by other factors to install and use the software.

The user must not be forced by other factors to enter the password and take measures which are not just unsafe but are actually known to attack the system, exfiltrate data or similar.




I agree totally.

But we haven't come up with any better methods of doing this. Some tasks require making changes to the machine that could be evil, so we have to ask the user for permission to make those changes (to stop evil people making those changes with no permission). The more parts of the device we protect, the more we have to ask for permission, and the more routine the granting of that permission is and the less effective the whole permission-granting mechanism is.

Coming up with a decent, workable, solution to this would be great. As you say, in an ideal world the onus would not be on the user to verify that the software they're installing is not malicious (with no way of effectively doing that).

hmm, sounds like a problem that could be lucrative to solve...




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: