
Using IM-Visor to stop untrusted IME apps from stealing sensitive keystrokes - christianbryant
https://cybersecurity.springeropen.com/articles/10.1186/s42400-018-0007-6
======
christianbryant
I think the cool factor here is that they "propose a new idea, pre-IME, which
guarantees that “Is this touch event a sensitive keystroke?” analysis will
always access user touch events prior to the execution of any IME app code."

In the paper they note as "a pre-IME design, IM-Visor always recognizes and
isolates sensitive keystrokes before the IMEs could access them. To achieve
this, whenever a user intends to type in a soft keyboard, the STIE will be
initialized to intercept touch events and analyze whether it is a sensitive
keystroke."

This model is one that begs a matching and reversed exploration of "sensitive
keystroke" emulation and whether such pre-IME analysis can be fooled.

------
olliej
I’m not sure this is a good solution, but maybe it’s the best “general” fix.

Basically an OS should be able to easily identify when you’re using a platform
password field for instance and not interact with the IM (although that causes
problems with assistive technologies). But the OS can’t really handle every
third party reimplementation of password fields. Presumably a 3rd party
solution would be able to rev faster and stay more up to date than the OS.
(The risk balance when the OS is involved is higher than for just the IM as if
it does break you can always remove the “visor”, but doing so in the os is
harder.

~~~
christianbryant
Agreed. I do like the creative thinking here, though. And it makes one think
about what an IM-Visor means for InfoSec outside this scenario; I'll be
honest, I've not thought about it and I see all sorts of topics here worth
exploration. For instance, what's to stop a malicious app to install and
emulate the IM-Visor essentially intercept the data "acting" as the pre-IME
defense stage?

