3 ms·

AFAIU it's the trojan app that uses the accessibility privileges? Which are probably only activated when the user activates them in the OS settings. Not sure i

AFAIU it's the trojan app that uses the accessibility privileges? Which are probably only activated when the user activates them in the OS settings. Not sure if possible, but perhaps the authenticator app could detect that accessibility mode is on, and refuse to show the codes? (or at least do it behind a warning?) Also, I think the trojan app would need to ask for accessibility permission from the user to be able to read other apps' text?

izacus 7y ago
So you would prevent blind people from using 2FA because someone else installed a tool that also reads screen? Please no.
- deleted 7y ago
  [deleted]
- tzs 7y ago
  You build speaking the OTP code into the authenticator app itself, controlled by a setting in the app itself rather than the system wide accessibility settings, and possibly using its own text to speech library instead of the system wide text to speech facilities. Whether or not it should use its own text to speech depends on whether or not you need to worry about malware subverting the system wide text to speech system. If it does use its own text to speech, it might be possible for it to just use the system text to speech system on install to do generate speech for the 10 digits and save that, and use those recordings for speaking codes. That avoids having to worry about system text to speech compromises except during authenticator app installation so is probably almost as safe is including a dedicated text to speech system, an ensures that they can handle all languages that the system text to speech can handle.
  - Macha 7y ago
    What about users that are deafblind and use external braille devices? Are you going to build support in for those too? Is the maker of every other security relevant app also going to?
  - Klathmon 7y ago
    But there's a lot more that goes into accessibility services. Redirecting all output to a single mono headphone is really important, and most users who use talkback adjust the speed and how things are spoken to better suit them. And it still doesn't solve the problem, as accessibility services can still tap into the audio output and run speech-to-text to get the codes back still accomplishing the same exact thing.
    - tzs 7y ago
      OK, so the idea of having the authenticator app entirely handle its own accessibility might not solve the problem in the case of users that are actually using accessibility features. Or at least it would require some serious system level support [1]. But how about the first part of my suggestion, which was to have whether or not accessibility features are used in the authenticator app controlled by a setting in the app separate from the system wide settings? For people not needing accessibility, at least, and so have it off both system wide and in the authenticator app they would be protected. A rogue app getting system wide accessibility access would still not get access to the authenticator. [1] The system might have to support two independent sets of accessibility privileges and settings, one for most apps and one for security apps, with severe restrictions on what regular apps can do when a security app is running.
shawnz 7y ago
> (or at least do it behind a warning?) Couldn't the accessibility app just approve the warning? Otherwise how would blind users do it?

izacus 7y ago

So you would prevent blind people from using 2FA because someone else installed a tool that also reads screen? Please no.

deleted 7y ago
[deleted]
tzs 7y ago
You build speaking the OTP code into the authenticator app itself, controlled by a setting in the app itself rather than the system wide accessibility settings, and possibly using its own text to speech library instead of the system wide text to speech facilities. Whether or not it should use its own text to speech depends on whether or not you need to worry about malware subverting the system wide text to speech system. If it does use its own text to speech, it might be possible for it to just use the system text to speech system on install to do generate speech for the 10 digits and save that, and use those recordings for speaking codes. That avoids having to worry about system text to speech compromises except during authenticator app installation so is probably almost as safe is including a dedicated text to speech system, an ensures that they can handle all languages that the system text to speech can handle.
- Macha 7y ago
  What about users that are deafblind and use external braille devices? Are you going to build support in for those too? Is the maker of every other security relevant app also going to?
- Klathmon 7y ago
  But there's a lot more that goes into accessibility services. Redirecting all output to a single mono headphone is really important, and most users who use talkback adjust the speed and how things are spoken to better suit them. And it still doesn't solve the problem, as accessibility services can still tap into the audio output and run speech-to-text to get the codes back still accomplishing the same exact thing.
  - tzs 7y ago
    OK, so the idea of having the authenticator app entirely handle its own accessibility might not solve the problem in the case of users that are actually using accessibility features. Or at least it would require some serious system level support [1]. But how about the first part of my suggestion, which was to have whether or not accessibility features are used in the authenticator app controlled by a setting in the app separate from the system wide settings? For people not needing accessibility, at least, and so have it off both system wide and in the authenticator app they would be protected. A rogue app getting system wide accessibility access would still not get access to the authenticator. [1] The system might have to support two independent sets of accessibility privileges and settings, one for most apps and one for security apps, with severe restrictions on what regular apps can do when a security app is running.

shawnz 7y ago

> (or at least do it behind a warning?) Couldn't the accessibility app just approve the warning? Otherwise how would blind users do it?