Интернет-банкинг для многих украинских пользователей — уже скорее дело привычки, чем новаторская услуга банка. Куда проще оплатить коммуналку или оформить платеж за пару кликов, чем стоять очередь. Правда, иногда банки предупреждают, что лучше бы пользователю открывать клиент в одном браузере, а не в другом, или вообще сводят выбор к единственному варианту. Редакция AIN.UA разобралась, откуда в украинском интернет-банкинге взялось ограничение по браузерам и будет ли оно существовать вечно.
Кто виноват
Это, на первый взгляд, странное ограничение не связано с техническими особенностями работы онлайн-банкинга какого-то одного банка. Банковский софт завязан на технологиях, которым нужна поддержка плагинов NPAPI (API, которое впервые было реализовано еще для браузера Netscape Navigator в 90-х годах), в частности, плагинов Java.
Новые версии популярных браузеров отказываются от поддержки таких плагинов из соображений безопасности. К примеру, 52-я версия Firefox, которая вышла в этом марте, больше не поддерживает NPAPI-плагины, в том числе — Silverlight, Java, Acrobat. Другие браузеры, вроде Chrome, прекратили эту поддержку еще раньше.
С этими ограничениями приходится сталкиваться не физлицам-пользователям интернет-банкинга, а ФЛП и юрлицам.
Например, чтобы оформить банковскую электронную подпись в «ПриватБанке», нужно качать программу, специально разработанную банком — CryptoPlugin. Его запустили еще в 2015 году, для решения «частых проблем с поддержкой браузерами апплетов Java». Правда, в банке обещают, что скоро софт клиент-банка обновится, чтобы с ЭЦП можно было работать без установки плагинов, а криптография будет реализована на JavaScript.
Другой пример: интернет-банкинг «ОТП Банк» для пользователей работает во всех браузерах. Но корпоративная версия недавно разослала клиентам предупреждение о том, что после обновления Firefox до 52-й версии единственным браузером, в котором клиент-банк будет работать корректно, останется Internet Explorer версии 9 и выше.
Что делать?
Ни Java, ни браузеры, в этой проблеме не виноваты, считает Павел Сиделев, CTO SDK.Finance: это особенность жизненного цикла банковского ПО. Эксперт приводит пример: предположим, 10 лет назад банк решил, что ему нужен интернет-банкинг. Его можно купить как готовое решение, либо же написать самостоятельно. Если покупать готовое у поставщика — любое изменение в продукте означает для банка дополнительные затраты.
«Один год для программного продукта — немалый возраст, 10 лет — это целая эпоха», — говорит Сиделев. Со временем даже сам Oracle, владелец технологии Java перестала поддерживать Java-апплеты, о чем и предупредила клиентов.
Если 10 лет назад Java-апплеты хорошо решали задачу «загрузить нужный софт в браузер клиента, не вынуждая его ставить отдельный клиент». Но со временем проявлялись критические уязвимости в самой Java Applet, ими заинтересовались хакеры. После ряда взломов браузеры начали сворачивать поддержку Java Applet, а потом отключили ее.
«С каждым годом для банка поддержка устаревающих технологий становится дороже, как и миграция на другую технологию. Предыдущие решения отказываются поддерживать сами производители браузеров, стоимость обновления стоит «дурных» денег, на собственную разработку или нет денег, или команды, которая справится с задачей. Банковские ПО — это непросто», — говорит Сиделев.
Иными словами, проблема с совместимостью — это проблема легаси-кода (устаревший код или же код от сторонних разработчиков, из старых версий).
С этим согласен и Дмитрий Дубилет, бывший IT-директор «ПриватБанка»: «Это все — легаси. Чтобы от него избавляться, надо, во-первых, иметь страстное желание, во-вторых, компетенцию, в-третьих, бюджеты… Писать под браузеры модули работы с ЭЦП — не так просто. Во-первых, беда с кросс-браузерностью. Во-вторых, много аспектов, связанных с безопасностью. Ведь в браузеры пользователи могут добавлять «левые» плагины». По его словам, тот же CryptoPlugin в свое время стал компромиссом между безопасностью и удобством.
Что банки могут сделать? По мнению Сиделева, можно реализовать middleware — средний слой ПО, которое позволяет присоединить к back-end-части банковского софта любой графический интерфейс, работающий на всех платформах. Это требует вложений, но не таких, как обновление всей инфраструктуры банка. «В настоящий момент разработчикам доступна масса новых фреймворков, которые позволят решить эту задачу малой кровью», — говорит он. Цена вопроса начинается от $20 000 и выше. По времени — реально уложиться в 3-6 месяцев для того, чтобы выдать наружу API, к которым можно «прикрутить» любой модный UI-движок.
Вместо выводов вспомним небольшую историю. В Северном Техасе живет 75-летний Билл Хиншоу, дедушка 36 внуков и правнуков. Он — эксперт в COBOL, и основал целую фирму, которая зарабатывает, помогая банкам в случаях, если нужно пофиксить софт, зависящий от этого древнего языка. Для кого-то легаси-код в финансовой сфере — проблема, а для кого-то — возможности.
