Lastpass says:
"The app needs this permission to provide a global, system-wide shortcut to bring up the search field, so that users can quickly locate a vault entry and copy passwords or launch sites. You can deny this permission request, as the Mac application will continue to work. It will just disable this function from working."
I bet it's similar here, they want a system-wide shortcut to get to google drive. Seems like an oddly named permission.
I like how they named it. If you can get permission for systemwide keystrokes it is also obviously able to see what you’re typing in other apps. More straightforward for those who are not tech oriented.
Doesn't linux work like this? Where certain input starts at the top (kernel), and then goes to the first program that "listens" for a certain key/combo?
So you could have a program only listen/capture certain keys?
Two different questions. You're talking about whether the app must get the user's approval. The question here (in this part of the thread) is whether the app must subscribe to all events and filter them itself or if it can instead subscribe to a filtered version of events.
You wouldn't, because Wayland is not ready for consumption by people that use their computer with expectations of full functionality. The obvious things for most people (shortcuts being one of them) do not yet work in it.
That works through the menu system, so any app that uses the standard menubar can have shortcuts reassigned. It works well, but it comes with the downside that the shortcuts are not global.
If we're at API design, I'd like an even more abstract one: Let the app register intents with associated title, description, icon and suggestion for a keyboard shortcut and let the OS manage how the intent is invoked.
Only because MacOS doesn't provide a more specific shortcut functionality. It should let an app register the specific keystrokes to get notified by, and doesn't need to notify which app was foreground when the shortcut was invoked.
Since the proper API isn't available, the principle of least privilege suggests that abusing a high-privilege, easily abused feature in an unorthodox manner to work around that problem might be a bad idea. Maybe MacOS shouldn't have this "systemwide shortcut" feature until it provides the necessary functionality. Currently that feature appears to be incompatible with the platform's security model; don't undermine that model just to make a hotkey feature work.
My guess is this API predates the introduction of these new security approvals. Some quick googling revealed that several developers are not even clear why their app causes the new macOS to ask the user for this approval.
I agree it's better not to have features that don't mesh with the security model, but when you're tightening down the security on an existing design, you may have to deal with awkward transitions. Even if they introduced a replacement API that fits with their security model better, a bunch of apps out there would have to be ported to use it, so they're going to need to maintain backward compatibility for a long while.
That's what I was wondering. I just came across this with the Google calendar API.
I was annoyed that the Facebook business appointments gcal sync wanted full access to read all my calendars and any calendars shared with me. All I want is for it to be able to add appts. But apparently, the gcal api doesn't have the granularity to even allow full access to a single calendar.
I guess this is some security model on Catalina. I couldn't find any info on what features of Google drive specifically would not work if you deny but there are plenty of questions online for different applications. Here's one for last pass:
This is really just an example of the impressive security policies of macOS, if I'm not mistaken as long as you have admin permissions you can trivially create a keylogger on Windows 10 without any such special permissions.
That philosophy has been very helpful to malware authors over the years. The modern approach has been to make that less of a binary decision and make sure the user can see it happening and change their mind: e.g. allow you to write an app which does something privileged but require a prompt and prevent it from hiding its actions.
History catching up to today's security environment.
This is also how permissions and APIs evolve over time. Apple (and hopefully other OSes) is likely working on a global hotkey hook system, that has a less intrusive permission requirement. Unfortunately it will take YEARs before applications in general start using that.
And this is Absolutely the correct thing for the OS to do.
Using dynamic overriding to intercept and NSLog calls to UIKeyCommand should be sufficient to find out precisely what key(s) they’re setting listeners for, but I don’t have the experience to finish this idea. Someone who’s familiar with dylib injecting would know:
I don't understand, I use skhd [0] which uses global shortcuts for things like window switching and I've never seen such a request. Unless asking for accessibility permission is the same thing, which I doubt (but admittedly don't know for certain).
So google drive is also a keylogger ? Not surprising.
I wonder - is there a way to look up app permissions without actually installing them ?
Which is to say, can I, using my web browser, browse either the apple app store, or google play store, and research, in advance, what a particular app is going to request (or demand) access to ?
I bet it's similar here, they want a system-wide shortcut to get to google drive. Seems like an oddly named permission.