Szoftver? Hardver?

Tegnapelőtt számolt be az IT café is arról a biztonsági hibáról, melyet német kutatók elemeztek és tártak a nyilvánosság elé, s mely gyakorlatilag szinte az összes ma használt, Android operációs rendszert futtató készüléket, zömükben okostelefonokat érinti. A Google azóta reagált a jelentésre, elindítottak egy javítási folyamatot – de erről majd később, részletesen.

Azért később, mivel ebben a történetben nem is a feltárt – egyébként már korábban is ismert – hiányosság játssza a főszerepet, hanem az a jelenség, amit a hiba, illetve annak javítási lehetőségei kapcsán láthatunk. Habár az Android elterjedése óta okoz gondokat a támogatási rendszer elégtelensége, valószínűleg ez a mostani incidens lesz az, amelynek hatására végre egy áldatlannak nevezhető állapotot felszámolnak az iparági szereplők.

Elszabadult

Mi is a gond? Az, hogy az IT-világ eddigi megszokásaival, elfogadott modelljeivel szemben itt egy olyan jelenséggel találkozunk, mely komoly aggályokat vet fel. A bevett forgatókönyv szerint, ha egy szoftvernél kiderülnek sebezhetőségek, biztonsági rések, működési elégtelenségek, akkor a frissítésekhez több-kevesebb idő után hozzájutnak a felhasználók – hogy ez meddig tart, milyen csatornákon zajlik, milyen technológia segíti ezt a folyamatot, az gyártó-, illetve cégfüggő, de a fontos az, hogy működik. A mostani androidos hiba azonban – bár nem elsőként, de az érintettek számát tekintve különösen hangsúlyosan – nem ilyen, ugyanis az a lehetetlen helyzet alakult ki, hogy hiába készített már a szoftvergyártó több olyan verziót, melyek tartalmazzák a javítást, hiába szeretnék a felhasználók ezt az új szoftvert használni, a speciális körülmények miatt erre nincs lehetőségük, ugyanis a hardvergyártói oldalról elzárkóznak a támogatás megadásától.

Hogy jöhetett létre egy ilyen, fogyasztóbarátnak messze nem nevezhető helyzet? Tartható-e ez hosszabb távon? Milyen érdekek ütköznek? Mi lehet a megoldás?

Ezt elemezzük most az alábbi cikkben.

Szoftver és hardver

Röviden teszem, de igen messziről kell elindulni, hogy a probléma lényege világos legyen. A kiindulási alap és a gondok forrása az, hogy a számítógépes program különleges termék. Szakemberek számára közhely és nyilvánvaló, hogy nem lehet „hibátlan” szoftvert írni. A szoftverfejlesztés inkább egy folyamat menedzselését jelenti, mint egy kódsor létrehozását, ugyanis a programok bonyolultsága miatt a lehető leglelkiismeretesebb munka mellett is emberileg és szakmailag képtelenség létrehozni egy olyan szoftvert, mely nem tartalmaz „hibákat”.

Ezek lehetnek alapvető működésbeli problémák, melyet a tesztek során nem, de a tömeges használat idején napvilágra kerülnek, de ma már a professzionális programok esetében ez a legkisebb szegmens. A hálózatos világban inkább két másik területen derülnek ki gondok: egyrészt nem lehetséges minden, a szoftver számára lehetséges környezetet modellezni, így rengeteg kompatibilitási hiba csak később, a használat során jön elő, másrészt pedig az internetes környezetben a ma leginkább fenyegető veszély a kiberbűnözés, és a programok esetében ma az adja a fejlesztők munkájának döntő részét, hogy a szoftvert biztonságossá tegyék, vagyis ne adjanak lehetőséget a crackerek számára, hogy a réseket kihasználva fontos adatokhoz jussanak, és megkárosítsák a felhasználókat. A fentiekből adódik az, hogy az új kihívásokra a programok frissítésével, az időközben feltárt hibák kijavításával kell a szoftverek gyártóinak reagálniuk.

A fentiek magától értetődőek egy szakember számára, ám az átlagfelhasználó sem ma, sem a jövőben nem fogja átlátni ezt a rendszert, ő kompakt, kész termékként kezeli a megvásárolt szoftvereket. A felvilágosítás sokat segíthet, de teljes eredményt soha nem fog elérni, így a szoftvergyártók igyekeznek a lehető legkönnyebbé, egyszerűvé tenni a frissítési mechanizmusokat, melyekre feltétlenül szükség van a mai informatikai környezetben.

Ebből a szempontból nézve jelenleg három jellemző típus található meg a tömegtermékek piacán (természetesen sok más is van, a vállalati szektorról most ne is beszéljünk, de ha a „mass marketről” van szó, a felosztás nagyjából helytálló).

Apple

Az egyik Apple-féle. Az ő termékeik legfontosabb jellemzője, hogy itt a hardver, illetve a szoftver gyártója ugyanaz a vállalat, amely ráadásul össze is köti ezt a két elemet, a hardver és a szoftver szoros és zárt egységet alkot. Itt most nem térnék ki e koncepció előnyeire és hátrányaira, csak a frissítések szempontjából nézzük meg a modellt. Ha egy Apple-terméknél kiderül egy szoftveres hiba, akkor egy jól bejáratott rendszerben (a hardver és a szoftver fejlesztője egy egységen belül van) a felhasználók egy idő után megkapják a cég által – hardveresen és szoftveresen optimalizált – javítást. Ezt kérhetik automatikusan, de elvégezhetik manuálisan is. A lényeg: a hiba kiderül, kijavítják, a frissítés hamarosan elérhető, a felelősséget maga a kompakt gyártó vállalja, aki igyekszik a fogyasztói elvárásoknak megfelelni.

Microsoft

A másik modellt hívhatjuk Microsoft-féle modellnek, ez legtöbb elemében gyökeresen különbözik az előbb tárgyalttól. A legfontosabb eltérés az, hogy ebben a koncepcióban a szoftverfejlesztő, -gyártó nem vállalja fel a hardverek előállítását, sőt, olyan programokat igyekszik készíteni, melyek „univerzálisak”, vagyis a lehető legtöbb platformon, szoftver-, illetve hardverkörnyezetben használhatóak. A programok kódja ebben a rendszerben is zárt, ám a vonzerőt az jelenti, hogy a gyártó cég hatalmas infrastruktúrát hoz létre annak érdekében, hogy a lehető legtöbb helyre eljuttassa megoldásait, melyeket a szigorú licencfeltételeknek köszönhetően karban is tart.

A zárt forráskód védi a cég szellemi termékét, ugyanakkor a vállalat azzal igyekszik ezt kompenzálni, hogy a fogyasztói elégedettség maximalizálása érdekében a licencfeltételekben jelentős mértékű, a hardver gyártójának kezét megkötő kötelezettséget vállal magára. Magyarul: ha egy Windowst vásárolunk, akkor a Microsoft két dolgot ígér (és ezt szinte mindig be is tartják): még a fejlesztési fázisban együttműködik a hardver gyártójával, hogy a vásárló egy jól működő, tesztelt, az adott hardverre optimalizált programot kapjon, emellett kötelezik magukat, hogy egy bizonyos ideig (ezt a cég mérnökei és menedzserei lövik be, a legtöbbször igen pontosan, sőt túltervezve), támogatást nyújtanak, ami az átlagfelhasználó számára azt jelenti, hogy az időközben kiderült hibákat frissítésekkel orvosolják (a felhasználó döntése szerint automatikusan vagy pedig manuálisan). A támogatások ebben a modellben olyan sokáig érvényesek, hogy akár több generációs hardverváltás után is hozzáférhetőek még a frissítések.

Az Android

A harmadik, valójában még alakuló modell egyrészt az okostelefonok megjelenésének, másrészt a Google által kiadott Androidnak köszönhető. Ez az, amiről jelenleg szó van, és ez az, aminek a hibáiról most szó kell essék.

A Google legnagyobb újítása az volt az előző kettőhöz képest, hogy egyrészt nyílt forráskódú operációs rendszert dobott a mobileszközök piacára, másrészt pedig – ebből következően – viszonylag laza licencfeltételeket állított fel. És itt jött elő az egyébként igen sok előnnyel kecsegtető nyílt forrás hátránya (pontosabban a használt licencelési megoldások hiátusa): a „szabadjára engedett” rendszer roppant előnyös volt a gyártóknak, mivel jelentős szabadságot biztosít számukra a testre szabás, a készülékekhez történő optimalizálás terén, ám a Google egy bizonyos mértékig elvesztette a kontrollt az általuk fejlesztett OS terén. Ezért állhatott elő az a helyzet, hogy – ahogy a mostani helyzet is világosan bizonyítja – a gyártók is a saját érdekeiket nézik, a szoftverfejlesztő is, és a kettő nincs harmonizálva.

A mind dinamikusabban fejlődő okostelefon-piacon a gyártók jelentős költségmegtakarításhoz jutottak úgy, hogy nem vállalták fel a készülékeken futó szoftverek támogatását. Egyszerűbben: hiába készít el a Google egy újabb verziót az Androidból, a gyártó takarékossági okból nem garantálja vásárlói számára, hogy a megvásárolt készüléken mindig a legújabb, legbiztonságosabb szoftver futhasson. Ezért fordulhatott elő az a helyzet, melyre a német kutatók újra felhívták a figyelmet: habár az Android már a 2.3.3-as, illetve korábbi hibás verziók után több frissítést is kapott, a készülékek 99,7 százalékán még mindig egy korábbi, sebezhető verzió található. (A statisztika a Google saját felmérésén alapul.)

A cikk még nem ért véget, kérlek, lapozz!