Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login
“Discord” would like to receive keystrokes from any application (twitter.com) similar stories update story
16 points by yawboakye | karma 913 | avg karma 2.08 2022-12-26 14:58:26 | hide | past | favorite | 26 comments



view as:

Discord has keyboard commands that enable features from the background while you're using a full screen input-focused application (like most games).

Whether you should trust them with that capacity to run a keylogger on your system is a good question though.


It's nothing to do with full-screen apps though -- it's specifically pertaining to PTT functionality for voice.

Simple solution: only allow the permission for specific keys.

Does any OS allow that?

Yes: https://github.com/flatpak/xdg-desktop-portal/pull/711

Requires DE integration. Currently works on KDE only.


It's for the PTT function, I assume.

It is, but they shouldn't force this on users either. I can understand wanting to use PTT while playing a game with some friends in a Discord chat, but more often nowadays it's used for group chats & meetings. Let me choose if I only want the keyboard shortcut to be accessible while in the app. I can't trust all of Discord's supply chain (who knows how many npm packages are in Discord) to not abuse this privilege.

It doesn't look like they are forcing it on you. You can choose to deny it, which seems to be the default option.

Of course they are. If I want PTT I have to enable it. Why? Let me do a keyboard shortcut for PTT while in-app. Let me push a UI button while app is focused. Give me alternatives. I have already been in group chats in Discord that enforce a "PTT must be enabled to talk" rule. Which I of course hate because I can't participate since I'm not willing to give keylogger access to all of npm.

They don’t force it, if you don’t allow it then the push-to-talk only works when Discord has focus.

The same thing happens in windows to some extent, especially if the app/game your using is running as admin then PTT won’t work unless Discord is also running as admin.


Sure they do force it. Allow me to do PTT while the app is focused without subjecting me to a terrible supply chain attack surface.

I don't use Discord for gaming comms. I just use it as a chat tool, and I don't need PTT outside of the app. Give me that option. It's not that hard to do.


It's literally not forced. It's asked as default to enable the PTT functionality.

They /could/ wait to make that request only after someone chooses the PTT option, but given they don't even communicate properly about why this dialog appears -- over 3 years after its introduction -- it's unlikely they're going to change it.

Would you rather they remove PTT functionality (which can reduce accessibility for some users), or that macOS didn't have such fine permissions? -- because that's the only way you're going to have that dialog go away...

If you don't trust the app or the "supply chain," don't use it. There are plenty FLOSS apps out there which have completely free client- and server-side source code you can review at your leisure, nobody is "forcing" you to use Discord.


Very simple: allow me to do PTT without system wide access. Give me the choice of PTT only while focused. Not that difficult. It is forced.

As said in other comments this is just for the Push To Talk support. It’s not mandatory in any way and users can just deny the permission and go on using the app (as long as they don’t need PTT, of course). So this is just yet another uninformed tweet that brings absolutely no information or anything useful.

nincompoop! i don’t even know where to start educating you from. as you can see from the comments, (1) it’s not immediately obvious what the use case is, but more importantly (2) discord is asking for permissions related to actions that may never be performed by the user. discord long escaped the confines of the gaming community. now, being a reasonable person, you’d wonder why discord will frighten the first-time installer this way, instead of what for a sure sign that the keylogging is indeed needed i.e. until the user has triggered any push-to-talk action. when that happens they could explain what it takes to make it work, and if user is still comfortable then they can trigger the permission request.

if this isn’t the logical thing you’d do, i pray i never have to use any software you work on since i'd gladly assume it's devoid of any thought, much less empathy.


Can you prevent an app from doing this by declining? How long has that permission system existed? And what does that permission system do to apps that predate the permission system?

On windows you can just add any global handler you want, and there’s now no way to prevent apps from doing that since that would be a breaking change.


Yes, you can prevent it -- if you decline permission, the app in question won't have access to the requested permission.

This was introduced in macOS Catalina (10.15), released in early October 2019. It's nothing new -- Discord are just useless at explaining it.

The permission in question is needed for any app that wants to read from things varying from keystrokes to your Contacts, or even full disk access (for reading your personal folders).

Any app requiring said permissions prior to Catalina would have to accept this, and if permission isn't given, access to the required resource isn't granted -- simple.


So do apps silently break or does the OS show a warning that “App Acme 1.0 attempted to use a global keyboard hook do you want to allow it?” at the point where the app makes the specific api call?

Fundamentally I guess it’s just a difference in philosophy in Windows. They basically say that “if it worked under Win32 20 years ago then it also works in Win32 20 years into the future, even if the behavior is an obvious bug”. Microsoft obviously release newer frameworks (UWP/Store/..) which allow for new restrictions, but few seem to want to give up access to the core platform and it’s unlikely to change.

The UAC system introduced a way of adding permissions with compatibility by popping up permission dialogs when required. But it doesn’t seem feasible to do for input hooks for example (I could be wrong here).


Why is this news?

It's nothing new -- the keystroke permission is required to enable Push-to-Talk (PTT), where you press or hold a key to activate the microphone in audio calls/chats.

Admittedly Discord have been terrible at stating this, and don't have a simple FAQ or explanation for something that's been going on for over 3 years, but there's nothing nefarious going on.

https://support.discord.com/hc/en-us/articles/360035130231--...


Does MacOS not allow you to request a specific hotkey? It doesn't appear so. Which means an app that wants to listen for a global hotkey it has to spy on every keystroke.

Discord doesn't have a choice if that's the case. Blame Apple for not providing a sane API.


Not quite -- this was designed to avoid developers using the "Input Monitoring" access, which covered whole-keyboard, etc. monitoring on a per-app level.

The permissions change is nothing new (introduced Fall 2019), and covers many more permissions than simply keystroke access.

Given the hotkey could be changed, keyboard-wide access makes the most sense -- would you really think it more "sane" to have to have a separate call and permission requests for each individual key, across apps?

Blame Discord for failing to communicate something that isn't a big deal, and hasn't been for the over 3 years this dialog has existed with it -- and worry more about what they're doing in the background, than Apple's APIs.


> would you really think it more "sane" to have to have a separate call and permission requests for each individual key, across apps?

Er, yes? I'd expect it to be something like on the first run you get a prompt like "foo wants to read ctrl+a, ctrl+b, and ctrl+shift+c even when it's in the background; allow?", and reprompt on changes (so you'd tell the app to change it, and then confirm to the OS that you're okay with it). I'd also personally be happy with the OS initiating things with a single control panel that listed all apps that can listen and you tell the OS what keys should signal what apps and how, but that might be too complex to ask people to use.

> Blame Discord for failing to communicate something that isn't a big deal

In fairness, also very much this; every app should always explain every single permission it requests.


Two things can be true:

1. This is for Push to Talk (PTT), and is not meant maliciously.

2. It's not good that an app is asking for this permission.

For #2, I'm not sure, but think the issue might be that Apple's system doesn't allow for sufficiently fine-grained permissions. Certainly that has been a repeated problem for other apps, as Apple has tried to improve end-user security.

Binding a hot-key to an action shouldn't require knowing anything about the stream of characters that a user is typing. But when the permission model isn't specific enough, that's what you get.

I think Apple's approach is mostly good (being able to listen to keystrokes without permission is very bad), but it has some costs.


I had this same problem, trying to provide PTT to an overlay object, but was freaking users out about permissions.

If anyone has a good solution, I'd appreciate to hear it(I just dropped the feature <- then 3 months later shut the project down and only use it for me now haha).


I suspect this is a UI decision rather than "we would like to spy". Say you're a person who wants to use Discord's special key commands (from other comments "push to talk" and similar?), then Discord can have a dialog that says "would you like to do this?" which is then followed by the linked dialog, or they can just use the OS dialog (to avoid double-dialog to the user). It seems that they've gone for the latter, but I think I've seen this which means they haven't done even the most basic usage gating (I've never used any kind of audio in discord, so PTT etc shouldn't be being attempted).

You could reasonably argue that this is an API shortcoming on macOS - there's no real way that I'm aware of to add a global key handler outside of accessibility APIs, and those APIs basically just let you do nothing or listen to everything and then filter the events in your app.


Legal | privacy