4 ms·
ActiveX is designed to hook directly into the Windows OS. That's what makes it so dangerous, but useful in this case, since you can add a cert to the trusted st
by itsameta4 13y ago
ActiveX is designed to hook directly into the Windows OS. That's what makes it so dangerous, but useful in this case, since you can add a cert to the trusted store.
Firefox is designed to be secure and sand-boxed, especially its plugin architecture.
- jlgreco 13y agoYou don't need to replicate all of the functionality that activex has. You just need to emulate the behaviour from the banks point of view of whatever their particular activex does. Maybe the ActiveX rewrites a bunch of files with admin privileges "for security", and then negotiates some sort of key exchange... in that case just write JS that says it did the shit that requires admin privileges, then negotiates the key exchange). So the question is, if you are willing to ignore their activex and run your own custom JS instead, could these websites be made to work?
- yongjik 13y agoA major online bookstore (www.aladdin.co.kr) actually tried that this year. They teamed up with another startup company (Paygate) and allowed users to use credit card with no plugins, on any browser. The few people who tried that loved it. And guess what happened? Major credit card companies pulled out one by one, because they "cannot ensure" that a page without Active-X is secure enough. Of course nobody's pulling any strings, no government officials are receiving unknown gifts, and nothing can be ever proved. So, there. You work for months to provide users with modern browsing experience, and those banking powers-that-be just pull the plug. The whole system is corrupt beyond imagination. Citation (sorry, in Korean): http://www.hankyung.com/news/app/newsview.php?aid=201309120399g http://www.hankyung.com/news/app/newsview.php?aid=2013091203... http://www.leejeonghwan.com/media/archives/002331.html http://www.leejeonghwan.com/media/archives/002331.html
- viraptor 13y agoThat's a solution from the provider's side though. I would have thought that it's much easier to handle it from the client side really... just pretend you did whatever verification was necessary and return the expected result. Noone should be able to shut it down, because it's on the client side, rather than the service provider, so the retailer shouldn't be blamed.
- yongjik 13y agoNo no no, it doesn't work that way. These banking websites don't expose a well-defined API that you can emulate. Instead they force you to install a bunch of ActiveX plugins (usually with administrative privilege) and you have to just trust that they won't, say, read the whole content of your hard disk and stream it to a third-party site. A few years ago (when I was still in Korea), it was usually impossible to open two different bank's pages at the same time: I'd assume that's still the case now. As far as I know, the reason is that both banks will force you to install "anti-hacking" plugins, which hooks directly into your Windows Kernel and makes sure nobody else snoops on what you type. Yes, these webpages try to establish a direct connection between your keyboard and the website, completely bypassing every layer. Now imagine the fun when two such plugins try to run at the same time. And of course without these plugins you can't use the site. Hell, sometimes these sites spontaneously break just because you're accessing it from the US, because nobody had thought to test them from a client with ping time > 200ms. Now try emulating that in client. (I don't know if I should laugh or weep.) EDIT: Besides, if you seriously try to make a platform that can emulate these "security" plugins, sooner or later you will be arrested for making tools to circumvent security measures, and people will be reminded that they should never install anything from "suspicious" sites. (But of course install everything from banking sites.) As a bonus, some news media will claim you were paid by North Korea, and many will believe that.
- viraptor 13y agoThanks, that's the part I haven't heard of before - good explanation of the issue. So if someone wanted to reimplement the client, they would have to reimplement a different one for every single site. Depending on the difficulty of working around the issue though, I wonder if it's a business opportunity: offer a web proxy which is transparent for all purposes, apart from the activex part - it would replace them with something that's either pretending to run the verification itself, or provides some replacement script. If you ran the company outside of Korea that took subscription money to bypass a number of the most popular services' auth, it would be hard to shut down. (but it would become a cat and mouse game of updating the algorithm until one side got bored...) Unfortunately this would have to be written in some interesting way that guarantees the passwords / tokens / sessions are never captured by this system, otherwise noone would use it. But that's a technical problem - should be doable in some way.
- jlgreco 13y agoThe idea is "Can I, the end user, do this without the banks knowledge or cooperation?"
- eevee 13y agoThis is completely false. Firefox extensions have access to everything the browser does and can contain arbitrary native code. There's a reason Mozilla's addon repository has a review process. What makes addons better than ActiveX controls is that they're understood to extend the browser for the user's benefit, not merely make a crappy website work. Fewer people would buy that a bank website needs to install a Firefox extension before you can log in.