Hacker News Reader

Comment by throwaway130917 | Hacker News Reader

Maybe it's time for desktop operating systems to adopt permissions systems like smartphones. Permission for network access, permission for non-current user files and registry, permission to install certs.

View on HN

Yes, why not?

Unfortunately all "secure" or "trusted" computing efforts seems to be focused on depriving the owner of permissions and command over the computer, and instead transfer that to large copyright holders.

But I suppose the Android security model would make sense, which seems to be based on a traditional unix security model combined with that each program will run as a separate user and having it's own set of group memberships.

As long as I don't need to install a rootkit on my own computer.

The problem is that non-technical users have no information on which to base their decision to allow or deny.

Consider a user that has no idea what SSL, TLS, Certificates, Encryption, HTTP, drivers, program signing even mean. What do you put in the prompt that would allow the user to make an informed decision about whether a program they downloaded should be able to install a cert?

We already have such prompts when trying to connect to a HTTPS website with an invalid/expired cert. It does a good job at discouraging to proceed, as it should. I see no reason similar prompt couldn't be shown when trying to install root CA on Windows machine. The problem with current Windows prompts is that they are all alike and shown too often, so users simply learned to ignore them. Actions, that may seriously affect safety and privacy (the category root CA falls into), should be protected by distinguish prompt, not the boring "run as administrator".

But when manually adding a root CA to the trusted root CA certificate store on Windows 10, you do get a warning.

Nothing.

If Microsoft (or any vendor) wants to sell security, they have to be responsible. Then they have to sign the drivers.

Yes, it's a whole lot of Single Point of Fuck, but that's what it takes. Hence we have the CA model. We have a "few" trusted authorities.

This could be made into a reputation market thing. So the user could buy security from a vendor. If a vendor is too strict, it'll have few users. If a vendor is too lax, we need a negative signal to penalize its reputation, maybe IP packets should contain a sort of fingerprint of the vendor. So if we see a lot of spam/DDoS from a vendor, it should cost them.

"Application is trying to access feature. Do you want to allow it?" Yes / No.

User testing revealed that most users clicked the little cross in the top corner.

I have watched users blindly click past dialogs that must have been showing up for them daily for years without ever showing the consciousness to click the "Do not show me this again" checkbox that has always been on that dialog.

:headwall:

That's good. They do that because it's easy to misunderstand the question. Closing the premission request is almost always the safest response. In this case, it would be the same as "Deny".

"Closing the premission request is almost always the safest response."

Except when it isn't: https://www.extremetech.com/extreme/229040-microsofts-latest...

Now we're talking about manipulative UX. I would even go as far as to call that "malware".

The original discussion was on the level of "assuming we can trust the OS that it's not trying to trick us, this dialog helps us decide whether to trust the app." As we have seen in the past, Windows no longer upholds this assumption.

The problem is how do you educate users on these prompts.

On smartphones permissions are pretty obvious (Camera, Contacts, Location, Pictures) but even they sometimes have consequences beyond the obvious.

How would would one even begin to word a certificate store permission so that the average person would understand the consequences of it?

The same way we taught them about the admin dialog ...

> " Mom, just click OK whenever this box pops up"

That's a tricky one. I'd say it's more important to clarify the significance of the permission. For instance:

> Do you trust this program to make security changes to your device? [More details]

"If I say no, will my app work? Because I'm installing this app so I want it to work. I'll probably just say "yes" because why would it ask me if it didn't need it?"

This is ultimately the problem. The dialog could say "This will trash your computer, empty your bank account, and kill your dog. Do you want to continue? YES/NO" and users will click YES if that's the only way to install whatever software they want to work.

This issue is hosted by developers making apps unavailable for installation lest agreeing to every requirement.

Developers get away with this because, 1) individually selecting permissions is growing rare and 2) there's no pressure to explain why a permission is needed, nor specific contracts to agree upon on how the general permission may be utilized.

Android used to about a crappy Samsung app on my phone in the details view:

- Using sys.whatever.whatever [redtext][Should only ever be used for debugging.]

I can't remember what app it was but it had an insane amount of unnecessary permissions even though it was just a simple app. I used to tell people it was my NSA app.

I consider myself tech savvy (by no means do I understand that much more than an average user). When I tried to enable my company’s mail on my personal iPhone, I was prompted to install a certificate. In my haste I thought it was just a certificate for *.my-company.com domains, but iPhone showed me a message in the likes of “the owner of the certificate would be able to read/modify all my network communication, monitor/install/uninstall all apps I have... “ and so on. That was enough to stop me in my tracks and now I’m waiting for a company phone instead.

Yeah, my company requires something like that if you want to access their stuff from your phone. By doing so you enable them to erase (non-company) stuff from your phone and monitor it. Most employees just say no at that point.

That's pretty common, and is one of the reasons for some of the third party exchange clients on Android devices. At least one of the early ones (Nitro?) maintained its own separate data store for email and possibly other things so that when policies were used to wipe data it could wipe only the data in that app instead of the entire device.

The counter to that is that now I believe there are a bunch of Exchange clients on Android that will simply ignore server policy or where handling of policy can be controlled in the settings, which kind of defeats the point.

The original point of all those policies was to be able to erase supposedly secure content if the device was lost or if someone left the company for whatever reason.

Edit: the Exchange client I was thinking of is TouchDown, now owned (and EOLed) by Symantec but I believe originally from NitroDesk.

This app would like to take over and monitor your internet connection. If you don't understand what this means, press no.

Don't forget to notify the user the reason their service isn't working as expected (if the permission is required).

Doesn't X509 certs tell what they are used for? Such as binary signing versus TLS signing?

The problem is how do you educate users on these prompts.

Same way you educate people on how to vote: functional literacy [0]. If people are functionally illiterate, they are going to struggle in all sorts of ways. One of the big drawbacks of our society is that its complexity seems to be growing without bound. This places ever-higher demands on people's ability to read, interpret, and act upon important information in their daily lives.

[0] https://en.wikipedia.org/wiki/Functional_illiteracy

That works on phones because app developers desperately want their (typically) free app to be installed and permissions is one thing that turns people away, so they try to minimise permission requests. Additionally, apps (at least on iOS) are expected to work even when some permissions are refused (eg. camera access for a shopping list app) so the permission request is often one you can genuinely say "no" to.

But device drivers for a desktop machine? The user has paid good money for that device and are going to grant every permission they need to get it working. Asking for each permission individually is just noise.

This is exactly what Windows 10 is doing with UWP apps. People hate it and complain about it and give it a bad reputation. But UWP apps have drastically reduced ability to torch your OS without permission, and have Android like permission grants on the Store page which say what access the app has to your system.

This is great etc.

But the problem is the user interface and programming environment is shit for anything past basic stabby finger novelty apps and no one trusts them enough to invest heavily in it. Oh and the store is a desert of turdblossoms.

You can put traditional desktop apps in the store using centennial bridge. No need to use special dev tools or ui frameworks.

https://developer.microsoft.com/en-us/windows/bridges/deskto...

Well, kind of. The issue is that Centennial also mostly overrides UWP's sandboxing. (Notice Centennial apps have "full access permission".) This is not a good solution, it is a stop gap.

UWP is more than capable of supporting advanced, quality desktop apps. The issue is just that while Windows 7 is so prevalent, developers have little reason to prioritize native UWP dev, which won't run on half the Windows userbase.

But why would you?

You’re more or less describing Qubes, which also does this in a way compatible with full user control (unlike smartphones).

The smartphone model where you click "yes" to everything?

And how would they do that? There is the Mac App Store and Windows Store, but most apps are still installed without using them due to their restrictions.

System call returns an error code if you lack permission. The default handler could be to ask, but if the user says no then the application has to handle the error or crash.

Still, if an audio driver wanted root access that wouldn't shock me.

I trust my distro vendor, but on Windows this likely remain the wild west for years to come.

Reply on news.ycombinator.com