8 ms·

Can you trust users to understand what the permission prompts really mean? Its like UAC in Windows where most people just press “yes” all the time.

klodolph 7y ago
Exactly. This is why when you double-click on an arbitrary app you downloaded on macOS, there is no “yes” button. You have to bypass the protection by right-clicking on the app or by changing system settings. This is also why if you access a website with a self-signed certificate, the browser will not give you a “yes” button to go through. You have to jump through a few hoops somewhere else (depending on browser) to accept the self-signed certificate, and then you can see the site. I think this is the right choice!
- strbean 7y ago
  I dislike the whole "Pop out the system settings dialog and enable things for the application" approach. It throws users into what is likely unfamiliar territory, which just obfuscates things further. I think a list of permissions with detailed explanations as to what they mean, and a Yes button, is a better approach. Although there needs to be an option to disable or even mock certain permissions.
  - Ididntdothis 7y ago
    Agreed. Especially since there is no explanation why the permission is needed and what it does in detail. I am a very experienced Windows dev but on my MacBook I have no idea what the exact implications are when an app requires access to “accessibility”. I am pretty sure the regular user doesn’t even have the foggiest idea but just does what he is told to do to make the app work. There is also no log what tells how the app uses the permission. It would be nice if there was a log of each use of the granted permission.
    - ryandrake 7y ago
      The rule of thumb I would use for an “accessibility” permission is: if the application’s purpose is specifically for disabled people (like a screen reader or magnifier for blind people), and you are disabled, then you should choose Yes. In all other cases always click No. Accessibility tends to be a “back door” permission that allows apps to do all sorts of powerful things they shouldn’t, like read the contents of everything you type and scrape the screen. “Normal” apps should never ask for accessibility. If they are, their developer is likely up to no good. Dropbox, for example, was recently in the news for silently granting itself accessibility permission, and Apple had to update the OS to prevent them from doing it. They still beg users to grant them this, even lying (EDIT: misleading users) on their web page about the purpose of the permission [1]. 1: https://help.dropbox.com/installs-integrations/desktop/mac-permissions https://help.dropbox.com/installs-integrations/desktop/mac-p... [EDITed instead of replying because HN limits the number of posts I can make for whatever reason.]
      - Ididntdothis 7y ago
        I have had several legitimate apps asking for accessibility permissions. I guess it comes down to the fact that permissions are not fine grained and specific enough. Same on android and iOS.
      - bobwaycott 7y ago
        This does not really work for things like tiling window managers on macOS—are you suggesting developers of such tools are up to no good, or are such system-control tools not fitting “normal”?
        ryandrake 7y ago
        If it can’t be done with non-a11y APIs then it doesn’t fit the definition of “things Apple thinks normal app should do,” whether we agree with that or not. The way I see it, and I know it’s a controversial view, if a developer is ok with flaunting the platforms rules about the purpose of an API[1], then what other behavior might they be ok with? 1: The first sentence in Apple’s accessibility API docs[2] is: “Accessible apps help users with disabilities access information and information technology.“ I think they are very clear about the purpose of these, and it’s not “to do cool innovative things missing from the regular API”. 2: https://developer.apple.com/library/archive/documentation/Accessibility/Conceptual/AccessibilityMacOSX/ https://developer.apple.com/library/archive/documentation/Ac...
- thenewnewguy 7y ago
  > This is also why if you access a website with a self-signed certificate, the browser will not give you a “yes” button to go through. You have to jump through a few hoops somewhere else (depending on browser) to accept the self-signed certificate, and then you can see the site. The button doesn't say "yes", but at least on FF there's a way to bypass the warning with one or two clicks from the error page itself. I think you might be confusing this with HSTS, where a certificate failure on an HSTS-enabled website will not let users bypass the warning (and for good reason).
  - klodolph 7y ago
    I'm not confusing this with HSTS. I'm being a bit vague because the UI is different for each browser. It used to be that you could just press one or two buttons, but these days the necessary buttons are usually either hidden, or in a separate settings page.
    - thenewnewguy 7y ago
      I just checked and it's one or two clicks on the same page (i.e. not a different location) for FF and Chrome. Maybe it's different in Safari (as we are talking about MacOS here), but I haven't used in so long for me to know.
  - mclehman 7y ago
    At least recently, HSTS failures could still be bypassed if you really wanted to (if, say, you made the bad choice of using the .dev tld for private domains). It's just completely undiscoverable for good reason.
privateSFacct 7y ago
The problem is the false alert - you HAVE to press yes all the time to get NORMAL work done. Same with cookie acceptance popups - supposedly this is allowing the user to know the website uses a cookie blah blah, but you HAVE to press yes in most cases to go forward - so everyone has now been trained to auto click yes all the time. At this point those popups could say anything and at least 10% of users would still click yes. I like the other approach. NO popup / warning unless something meaningfully unexpected. The problem is there are bunch of warriors on the net and elsewhere that do things like claim that users hate cookies and won't accept them, so need to be warned of them by every website (which can still technically set cookies regardless of any popup). If users don't want cookies they can block them at the browser level - that's how you have actual control BTW - a scam site may not put up the cookie notice and may still be able to set the cookie. Meanwhile - no notice required when your ISP tracks your every move AND is the monopoly provider. The internet folks have priorities totally backwards - so much focus on evil google it is ridiculous. The reason many people give google their entire search / email history is that they trust google more than the Chinese phone folks, the samsungs, the comcasts etc. Some real actions to improve the net: We need actual criminal prosecution and responsibility for websites distributing malware, browser exploits or downloadable. Owner goes down even if it was their ad network, they can then sue the ad network and if they can recover from them great, if not they still pay for picking a crappy ad network. If their webhost was hacked they still pay for picking stupid web host, they can then sue webhost to recover. We need to ban and criminally prosecute sale of info by places like ISPs and DMV's that are monopoly providers that have strong paid revenue streams already.
- saagarjha 7y ago
  Users don't want cookies. It's just that websites have made their tracking apparatus dependent on them, so they force users to accept them if they'd like to access the site. > Meanwhile - no notice required when your ISP tracks your every move AND is the monopoly provider. Yeah, no. Nobody likes their ISP, it's just that it's a lot harder to enact change here.
  - cortesoft 7y ago
    I mean, I want cookies on lots of sites... like any one that I login to. How else are they supposed to track access to my account?
chx 7y ago
Hoyvin-Glavin! https://twitter.com/PowerDNS_Bert/status/1171352665164529665 https://twitter.com/PowerDNS_Bert/status/1171352665164529665
strig 7y ago
UAC is even more useless, it just tells you "Do you want to allow xyz to make changes to your computer", without telling you what any of those changes or permissions are. Android permission prompts are way better.
- gruez 7y ago
  >UAC is even more useless, it just tells you "Do you want to allow xyz to make changes to your computer", without telling you what any of those changes or permissions are. The UAC prompt is essentially "sudo" - it grants root to whatever program is running. You really can't really implement a more granular permissions system without significant engineering effort, because you need to ensure that granting one permission doesn't result in privilege escalation. For instance, granting permissions to modify Program Files/Windows directory can be abused to get steal permissions from other applications, by replacing existing executables with malicious ones. >Android permission prompts are way better. Not really comparable because "regular" Windows programs aren't sandboxed. So they kinda already all the android "permissions" already (eg. contacts - they can simply read off disk). A better comparison would be root, which essentially has the same ux as Windows UAC.

klodolph 7y ago

Exactly. This is why when you double-click on an arbitrary app you downloaded on macOS, there is no “yes” button. You have to bypass the protection by right-clicking on the app or by changing system settings. This is also why if you access a website with a self-signed certificate, the browser will not give you a “yes” button to go through. You have to jump through a few hoops somewhere else (depending on browser) to accept the self-signed certificate, and then you can see the site. I think this is the right choice!

strbean 7y ago
I dislike the whole "Pop out the system settings dialog and enable things for the application" approach. It throws users into what is likely unfamiliar territory, which just obfuscates things further. I think a list of permissions with detailed explanations as to what they mean, and a Yes button, is a better approach. Although there needs to be an option to disable or even mock certain permissions.
- Ididntdothis 7y ago
  Agreed. Especially since there is no explanation why the permission is needed and what it does in detail. I am a very experienced Windows dev but on my MacBook I have no idea what the exact implications are when an app requires access to “accessibility”. I am pretty sure the regular user doesn’t even have the foggiest idea but just does what he is told to do to make the app work. There is also no log what tells how the app uses the permission. It would be nice if there was a log of each use of the granted permission.
  - ryandrake 7y ago
    The rule of thumb I would use for an “accessibility” permission is: if the application’s purpose is specifically for disabled people (like a screen reader or magnifier for blind people), and you are disabled, then you should choose Yes. In all other cases always click No. Accessibility tends to be a “back door” permission that allows apps to do all sorts of powerful things they shouldn’t, like read the contents of everything you type and scrape the screen. “Normal” apps should never ask for accessibility. If they are, their developer is likely up to no good. Dropbox, for example, was recently in the news for silently granting itself accessibility permission, and Apple had to update the OS to prevent them from doing it. They still beg users to grant them this, even lying (EDIT: misleading users) on their web page about the purpose of the permission [1]. 1: https://help.dropbox.com/installs-integrations/desktop/mac-permissions https://help.dropbox.com/installs-integrations/desktop/mac-p... [EDITed instead of replying because HN limits the number of posts I can make for whatever reason.]
    - Ididntdothis 7y ago
      I have had several legitimate apps asking for accessibility permissions. I guess it comes down to the fact that permissions are not fine grained and specific enough. Same on android and iOS.
    - bobwaycott 7y ago
      This does not really work for things like tiling window managers on macOS—are you suggesting developers of such tools are up to no good, or are such system-control tools not fitting “normal”?
      - ryandrake 7y ago
        If it can’t be done with non-a11y APIs then it doesn’t fit the definition of “things Apple thinks normal app should do,” whether we agree with that or not. The way I see it, and I know it’s a controversial view, if a developer is ok with flaunting the platforms rules about the purpose of an API[1], then what other behavior might they be ok with? 1: The first sentence in Apple’s accessibility API docs[2] is: “Accessible apps help users with disabilities access information and information technology.“ I think they are very clear about the purpose of these, and it’s not “to do cool innovative things missing from the regular API”. 2: https://developer.apple.com/library/archive/documentation/Accessibility/Conceptual/AccessibilityMacOSX/ https://developer.apple.com/library/archive/documentation/Ac...
thenewnewguy 7y ago
> This is also why if you access a website with a self-signed certificate, the browser will not give you a “yes” button to go through. You have to jump through a few hoops somewhere else (depending on browser) to accept the self-signed certificate, and then you can see the site. The button doesn't say "yes", but at least on FF there's a way to bypass the warning with one or two clicks from the error page itself. I think you might be confusing this with HSTS, where a certificate failure on an HSTS-enabled website will not let users bypass the warning (and for good reason).
- klodolph 7y ago
  I'm not confusing this with HSTS. I'm being a bit vague because the UI is different for each browser. It used to be that you could just press one or two buttons, but these days the necessary buttons are usually either hidden, or in a separate settings page.
  - thenewnewguy 7y ago
    I just checked and it's one or two clicks on the same page (i.e. not a different location) for FF and Chrome. Maybe it's different in Safari (as we are talking about MacOS here), but I haven't used in so long for me to know.
- mclehman 7y ago
  At least recently, HSTS failures could still be bypassed if you really wanted to (if, say, you made the bad choice of using the .dev tld for private domains). It's just completely undiscoverable for good reason.

privateSFacct 7y ago

The problem is the false alert - you HAVE to press yes all the time to get NORMAL work done. Same with cookie acceptance popups - supposedly this is allowing the user to know the website uses a cookie blah blah, but you HAVE to press yes in most cases to go forward - so everyone has now been trained to auto click yes all the time. At this point those popups could say anything and at least 10% of users would still click yes. I like the other approach. NO popup / warning unless something meaningfully unexpected. The problem is there are bunch of warriors on the net and elsewhere that do things like claim that users hate cookies and won't accept them, so need to be warned of them by every website (which can still technically set cookies regardless of any popup). If users don't want cookies they can block them at the browser level - that's how you have actual control BTW - a scam site may not put up the cookie notice and may still be able to set the cookie. Meanwhile - no notice required when your ISP tracks your every move AND is the monopoly provider. The internet folks have priorities totally backwards - so much focus on evil google it is ridiculous. The reason many people give google their entire search / email history is that they trust google more than the Chinese phone folks, the samsungs, the comcasts etc. Some real actions to improve the net: We need actual criminal prosecution and responsibility for websites distributing malware, browser exploits or downloadable. Owner goes down even if it was their ad network, they can then sue the ad network and if they can recover from them great, if not they still pay for picking a crappy ad network. If their webhost was hacked they still pay for picking stupid web host, they can then sue webhost to recover. We need to ban and criminally prosecute sale of info by places like ISPs and DMV's that are monopoly providers that have strong paid revenue streams already.

saagarjha 7y ago
Users don't want cookies. It's just that websites have made their tracking apparatus dependent on them, so they force users to accept them if they'd like to access the site. > Meanwhile - no notice required when your ISP tracks your every move AND is the monopoly provider. Yeah, no. Nobody likes their ISP, it's just that it's a lot harder to enact change here.
- cortesoft 7y ago
  I mean, I want cookies on lots of sites... like any one that I login to. How else are they supposed to track access to my account?

chx 7y ago

Hoyvin-Glavin! https://twitter.com/PowerDNS_Bert/status/1171352665164529665 https://twitter.com/PowerDNS_Bert/status/1171352665164529665

strig 7y ago

UAC is even more useless, it just tells you "Do you want to allow xyz to make changes to your computer", without telling you what any of those changes or permissions are. Android permission prompts are way better.

gruez 7y ago
>UAC is even more useless, it just tells you "Do you want to allow xyz to make changes to your computer", without telling you what any of those changes or permissions are. The UAC prompt is essentially "sudo" - it grants root to whatever program is running. You really can't really implement a more granular permissions system without significant engineering effort, because you need to ensure that granting one permission doesn't result in privilege escalation. For instance, granting permissions to modify Program Files/Windows directory can be abused to get steal permissions from other applications, by replacing existing executables with malicious ones. >Android permission prompts are way better. Not really comparable because "regular" Windows programs aren't sandboxed. So they kinda already all the android "permissions" already (eg. contacts - they can simply read off disk). A better comparison would be root, which essentially has the same ux as Windows UAC.