by curling_grad on 1/9/23, 6:58 AM with 52 comments
by maeil on 1/9/23, 12:45 PM
This is a bit of an exaggeration. Plenty of young people hate this stuff enough that they do all of their banking through their phone and if they absolutely must do it on a pc, they either use an old disused laptop, do it at work, do it at an internet cafe (not that those don't bring risks) or make sure to remove the spyware the second they've completed the task at hand.
by pvg on 1/9/23, 8:47 AM
by kweingar on 1/9/23, 8:27 AM
I have my reservations with the browserfication of software (and the restriction of browser extensions), but at the same time it is absolutely for the best that normal users just run sandboxed phone apps and browsers these days. Hopefully South Korea will retire this tool soon.
by choeger on 1/9/23, 8:23 AM
by goranmoomin on 1/9/23, 5:39 PM
Everybody knows that the systems are absurd. Most newer systems don’t require the use of such anti-keylogger programs. This is basically a countrywide legacy that we’re figuring our way out for ~30yrs.
This started in the 90s where South Korea got high speed internet everywhere, and people demanded internet banking… when IE didn’t ship 128-bit AES support due to export laws.
The South Korean govt submitted a law to enforce encryption for such services (i.e. an custom algorithm called SEED and 128-bit or higher keys were required), and without IE support, these encryption were developed in ActiveX. (For who don’t know, it was a COM-based solution to load native code from IE.) Laws and protocols are sticky, and even after IE shipped better encryption, these stayed.
When the anti-keylogger idea was first proposed, it was simple: the anti-keylogger could ship with the encryption support. It was when IE didn’t have a yes/no dialog to ask whether to load native code or not; everything felt easy, and at that point everybody got locked into this legacy mess where nobody could use different browsers other than IE.
When IE added confirmation dialogs, banks instructed customers to press yes. When IE deprecated ActiveX, banks didn’t remove their 20-yr old code straight away; people were advised to turn on ActiveX support from advanced settings (they added step-by-step instructions to help people), and when MS finally ripped out ActiveX, banks just copied their ActiveX components into a separate executable that runs a localhost server. (And that explains the hastily coded JSON support, the never-updated libraries, and so on that the article shows.)
Every time MS tried making running untrusted native code harder, the banks and customers got used to it… until it became acceptable to install 2~3 different executables for each bank, each running a server on a different port.
Thanks to smartphones, newer solutions now develop all of the encryption code in JS, and the legacy now runs in JS without native code. Still legacy, but it’s been much better for the last 5yrs.
by snvzz on 1/11/23, 10:54 AM
Note this is written by Norman Feske, who later went on to develop Genode[1], and continues to be its main developer today.
by lxgr on 1/9/23, 9:57 PM
> The current approach is for the websites to use WebSockets API to communicate with the application directly.
Is this really current best practice? I know of a handful of applications that implement webapp to native app communication like this, but it doesn't seem especially stable/portable to me, considering that it usually uses some ephemeral port that applications have no way of globally reserving.
Also, how does HTTPS work in this scenario? Wouldn't there be a self-signed certificate or mixed content warning in many cases?
by tlranfdnjsror on 1/9/23, 4:17 PM
Probably just some minor temporary weirdness but > Host palant.info not found: 3(NXDOMAIN)
by fomine3 on 1/10/23, 1:41 AM
by tgsovlerkhgsel on 1/9/23, 6:30 PM
by ThrowAgain on 1/9/23, 8:30 AM
by leshenka on 1/9/23, 8:11 AM
by stargtmail on 1/9/23, 8:29 AM
by wkat4242 on 1/9/23, 9:00 AM