Netes technológiák

Fő kategória: Böngészés.

HTTP alapok

Érdemes tisztában lennünk annak az alapjaival, hogy mi módon kommunikál a böngészőnk a szerverrel. HTTP-nek nevezzük azt a protokollt, ami ezt definiálja; ez a HyperText Transfer Protocol rövidítése. A HTTP tehát az a csatorna, ahol az adat megérkezik a szerverről a böngészőnkbe.

A legfontosabb: a kommunikáció formája kivétel nélkül olyan, hogy a böngésző kérdez, és a szerver válaszol. Ez egy sok évtizedes örökség, és technikailag nem lehetséges, hogy ez máshogy történjen. Tehát akármennyire is azt gondoljuk, hogy a túloldal küld nekünk valamit, az mindig úgy történik, hogy a böngésző folyamatosan lekérdezi az adatokat. A chat alkalmazás is így működik: ha küldünk valamit, azt elküldi a böngésző, a válasz viszont mindig úgy érkezik, hogy a böngésző folyamatosan kérdezi a szervert, írt-e már a másik valamit.

HTTPS

A weboldalak többsége előtt vagy http vagy https van, és ez utóbbi egyre inkább egyeduralkodóvá válik. Az s a secure (biztonságos) szóra utal. Mit jelent ez? A http önmagában miért nem biztonságos, és mit jelent ez? Alapból az adat titkosítatlan módon megy egyik számítógéptől a másikig. Viszont ez a legritkább esetben megy közvetlenül: általában több szerveren keresztül megy, mire megérkezik a címzetthez, ráadásul az útvonal előre megjósolhatatlan. Ezek a szerverek "le tudják hallgatni" az adatforgalmat. Publikusan elérhető tartalom esetén (mint pl. ez a weboldal) ennek túl nagy jelentősége nincs, de ha pl a jelszavunkat is megadjuk, azt már nem szeretnénk, hogy ellenőrizetlenül bárki kezébe jusson, ahogy a magánlevelezésünk vagy a bankszámlánk kivonata sem. Márpedig egy titkosítatlan csatornán a jelszavak lopása technikailag lehetséges, sőt, technikailag kimondottan egyszerű.

A https csatorna titkosított. Kissé elnagyoltan a következő történik:

  • A böngésző generál egy egyszer (vagy kevésszer) használatos publikus-privát RSA kulcspárt.
  • A kiszolgáló szerver elküldi (egészen pontosan: a böngésző lekéri) az ő kulcsát.
  • Ez utóbbi nem egyszer használatos, hanem tartós, és általában egy külső tanúsítvány hatóság (Certificate Authority, CA, pl. VeriSign stb.) adja ki, vagy legalábbis hitelesíti. Számos esetben találkozhatunk figyelmeztetéssel, hogy "ez a weboldal nem biztonságos", és valami kivételt kell valahova hozzáadni. Ez technikailag azt jelenti, hogy az az oldal olyan kulcsot használ, amit nem írt alá általánosan elfogadott CA. Attól még valódi a tanúsítványa, de nyilván nem annyira megbízható, mintha egy hatóság ellenőrizte volna a cégadatokat. A kivétel pedig azt jelenti, hogy csak az adott böngésző által elfogadott tanúsítvány kezelő cégek által kiadott tanúsítványokat fogadja el, hanem kivételesen ezt is.
  • A böngésző a kéréssel elküldi a publikus kulcsot.
  • A böngésző a kérést a szerver publikus kulcsával titkosítja, míg a szerver a választ a böngésző publikus kulcsával.
  • A privát kulcs birtokában az adat pillanatok alatt dekódolható, anélkül viszont szinte lehetetlen. Magát a tartalmat tehát a köztes szerverek így nem láthatják, még az internet szolgáltató sem.
  • Az internet szolgáltató a szervert magát viszont továbbra is látja; ezt VPN segítségével lehet eltitkolni, ld. később.

Az internetes biztonságról

Fontos tudunk, hogy a fent leírtak csak az internetes biztonság technikai részleteit tartalmazza. Hiába védjük szinte feltörhetetlen kódolással a jelszavunkat, ha azt aztán kérésre megadjuk másoknak. Az internetes biztonság leggyengébb láncszeme nem a technológia, hanem az ember. Mindenre nem tudunk felkészülni, de pár dolgot meg kell fontolnunk:

  • Soha senkinek ne adjuk ki a jelszavunkat! Ahogyan a banki belépési kódunkat és úgy általában semmit, amivel kárt tudnak nekünk okozni.
  • Futtatható szoftvert csak megbízható forrásból töltsünk le. Ha pl. egy pdf-et szeretnénk letölteni, és az oldal arra kér, hogy telepítsünk fel egy szoftvert a saját gépünkre, akkor ne tegyük.
  • Csak annyit osszunk meg magunkról, amennyit feltétlenül fontos; esetenként még annyit se! Ne feledjük: az internet nem felejt!
  • Az internet veszélyes hely! A gyerekeknek különösen óvatosnak kell lenniük! Láthatunk (rém)filmeket arról, hogy milyen könnyű elcsalni egy gyereket a való életben; hát még az interneten!

Azonosítás

Szorosan kapcsolódik a fenti témához. Az azonosítás célja az, hogy a személyes adatokat csak mi érhessük el, de mi elérjük.

Először is ehhez kell egy azonosító. Látszólag egyszerű a téma, a valóságban nem az. A problémát az okozza, hogy évtizedek alatt sok száz rendszerhez regisztrálunk, és az azonosítót könnyen elfelejtjük. Pl. ha tudok, úgy regisztrálok, hogy csaba, a következő az fcsaba, faragocsaba, farago.csaba stb., és ha ezek mind foglaltak, akkor a születési évemmel játszok. De vajon adott esetben sikerült elcsípnem a csabát? Vagy fcsaba lettem? Vagy valami más? Sok esetben nem emlékszem. Az e-mail cím viszont egyedi (nyilván nincs két ember, akinek ugyanaz lenne az email címe), és viszonylag stabil. A jó azonosító igazából az e-mail cím, és nem egy azonosító, különösen nem egy, a szolgáltató által generált azonosító. (És most álljuk meg egy pillanatra, gondoljuk a magyar állami weboldalak által folytatott gyakorlatra. Elkeserítő.)

Az azonosítás másik neve autentikáció. Ennek számos módja lehetséges:

  • Jelszó: a leggyakoribb megoldás. A legtöbb rendszer adott minimális összetettségű jelszót követel meg (pl. legalább 8 karakter hosszú, tartalmazzon kisbetűt, nagybetűt, speciális karaktert és számjegyet is), valamint a jelszó adott rendszerességű megváltoztatását, ráadásul úgy, hogy az nem egyezhet meg a korábbiakkal.
  • Kód: a kétlépcsős azonosítás leggyakoribb módja, amikor küldenek egy kódon e-mailben vagy SMS-ben, amit be kell írni a jelszó mellé. Ez jelentősen növeli a fiókunk biztonságát: ugyanis nem elég ellopni a jelszót, hanem az e-mail fiókunkat is fel kell törni, vagy a telefonunkat ellopni. De ez sem biztos, hogy elég, mivel a telefonunknak célszerűen van zárja. A kettős azonosítás annyira összetetté teszi a fiók feltörését, hogy érdektelenné teszi a hekkereket a jelszavak kitalálására.
  • Kulcs: valószínűleg ez a legbiztonságosabb, de technikailag a legnehezebb. Ez esetben generálni kell egy publikus-privát kulcspárt. A publikus részét regisztrálni kell a szerveren, és a privát kulcs birtokában lehet csak bejelentkezni. A privát kulcsot viszont szuperbiztos helyen kell tartanunk. Ha nem lopja el senki a privát kulcsot, akkor gyakorlatilag feltörhetetlen.
  • Token: egyszer használatos, általában 6 jegyű számsort jelent. Egy ilyen token percenként újabb számot generál, így csak egy percig érvényes. Adott számítógéphez kell regisztrálni. Fontos, hogy a rendszerórák összhangban legyenek. A dolgot lehet PIN kóddal bonyolítani: ez esetben nem elég ellopni a számítógépet és a tokent, a PIN kódot is tudni kell a használathoz. A tokennek van soft token változata is, pl. a Google Hitelesítő nevű app; ebben az esetben egy QR kód beolvasásával lehet összekapcsolni a számítógépet és az okostelefont, és az app által kiírt kódot kell beírni a megfelelő helyre. A legismertebb kliens a Cisco AnyConnect, ahol a szervert, a felhasználó nevet és az aktuális számot kell beírni.

Érdemes különböző rendszereken különböző jelszókat használni. Sok jelszót persze nehéz fejben tartani. Egy tipp: használjuk mindenhol ugyanazt egy könnyen megjegyezhető postfix-szel, pl. [szokásosjelszó]-facebook, [szokásosjelszó]-gmail, [szokásosjelszó]-skype. Ez amiatt jó megoldás, mert a jelszavakat nem natív formában, hanem kódolva tárolják az adatbázisokban úgy, hogy azt nem lehet visszafejteni (egy bejelentkezésnél tehát végrehajtják a kódolást, és akkor enged be, ha az eltárolt kód és a kiszámolt kód megegyezik), viszont a kódolás olyan, hogy pici, akár egy bitnyi változás is teljesen más módot eredményez. Ha pont ugyanazt használjuk mindenhol, akkor az a tény egyből látszik, hogy ugyanazt használjuk (mert ugyanaz a kódja), és egy helyen feltörték, akkor egyúttal az összeset feltörték, ha viszont eltérő a kód, akkor nem tudhatják, hogy csak minimálisan tér el egy már feltörttől, vagy teljesen mást használunk.

A valóságban ennél nagyobb biztonságban vagyunk. Komolyabb rendszerekben a jelszavakat "sózzák", azaz véletlen generált adatot adnak hozzá. Ezt a sót elmentik, így belépéskor a sóval együtt számolja ki a kódot. Mivel különböző rendszereknél különböző só generálódik, ráadásul ha két felhasználó véletlenül ugyanazt a jelszót használja, az eltérő só miatt a tárold jelszó eltérő lesz.

Amit mindenképpen el kell kerülni: szótári szavak használata, vagy csak számok használata, ugyanis ezeknek (ill. ezek egyszerűbb kombinációinak) a hash kódjai eleve le vannak mentve nagy adatbázisokban, így számolás nélkül gyorsan kitalálhatóak.

Néhány azonosítással kapcsolatos egyéb technológia:

  • OAuth: ez az a technológia, amikor egy más rendszerhez regisztrált fiókkal lépünk be egy adott rendszerbe. Pl. Gmail vagy Facebook fiókkal tudunk használni ezektől feljesen független oldalt. Nagy vonalakban a működése a következő: ha a felhasználó egy kliens alkalmazáson keresztül szeretne hozzáférni egy erőforráshoz, amihez azonosításra van szükség, akkor az az erőforrás továbbítja a kérést az OAuth szervernek (pl. a Gmail-nek). Ekkor a felhasználó megadja a jogosultságot (ez akkor történik, amikor rákattintunk a böngészőben arra, hogy ezzel és ezzel a Gmail fiókkal szeretném végrehajtani a műveletet), az OAuth szerver (azaz a Gmail) generált egy tokent, amit elküld a kliensnek (annak az oldalnak, ahova be szeretnénk lépni Gmail fiókkal), és az ezzel a tokennel már eléri a kívánt erőforrást. A folyamatnak van egy rendkívül lényeges mozzanata: a jelszavunkat NEM adtuk meg a kérdéses szolgáltatásnak, mégis el tudott járni a nevünkben.
oauth.png
  • Captcha: sokszor előfordul, hogy nem elég a jelszó meg miegyéb, még be kell írni egy alig olvasható generált valamit, sőt olyan is van, hogy egy négyzetrácsra osztott képen be kell jelölni, hogy adott tárgy mely négyzeteket érinti. Ez az ember ellenőrző: a gyorsteszt arra vonatkozik, hogy megállapítsa, emberek vagyunk-e vagy nem. Ezzel kerülik el a szerverek a programozott támadást, pl. azt, hogy egy program végigpróbáljon nagyon sok jelszót. Az igazság ezzel kapcsolatban egyébként az, hogy - tapasztalatból írom - elég alacsony a találati arány, és a mesterséges intelligencia már megközelítette az emberét e tekintetben. A "nem vagyok robot" egy kevésbé bosszantó megoldás, már csak amiatt is, mert 100%-os a találati arány. De vajon miért működik? Ezt JavaScript generálja (tehát nincs ott hagyományos HTML elemként, amit egy robot is felismerne), amit egy program "nem lát", az ember viszont igen.

Az autentikáció mellett fontos fogalom még az autorizáció: az autentikáció ugyanis csak annyi, hogy igazolom, az vagyok, akinek állítom, hogy vagyok. Az autorizáció arról szól, hogy mihez van jogosultságom. Pl. a bankban hiába tudom hitelt érdemlően bizonyítani, hogy Faragó Csaba vagyok, a szomszédom számlájára akkor sem kapok betekintést, mert nincs hozzá jogosultságom. A legtöbb esetben ezzel nincs teendőnk: a saját dolgainkhoz általában hozzáférnünk, ill. ahhoz, amit velünk megosztottak (ami leggyakrabban azt jelenti, hogy olyan csoporttal melynek mi magunk is tagjai vagyunk), máshoz meg nem. De kivételek itt is vannak. Egy internetes fizetésénél vagy banki átutalásnál sokszor külön meg kell erősíteni a tranzakciót, többnyire oly módon, hogy be kell írni egy SMS-ben küldött kódot vagy egy okostelefonos alkalmazásban jóvá kell hagyni azt. Ez a művelet autorizációnak minősül: egy adott műveletet hagyunk jóvá vele. Autorizáció egy telefonhívás is lehet: szokatlan vásárlás esetén felívhatnak a bankból, hogy megerősítsük vásárlási szándékunkat.

IP

Minden internetre kötött eszköznek egyedi azonosítója, ún. IP címe van. Ez az azonosító 32 bit hosszú, így kb. 4 milliárd különböző értéket vehet fel. Az IN cím szokásos jelölése a következő: a 32 bitet 4 darab 8 bit hosszú részre osztjuk, mindegyik 8 bites hosszú résznek vesszük a 0…255 tartományba eső számértékét, és ezeket pontokkal választjuk el. Például 94.44.225.116. (Ez konkrétan az én számítógépen IP címe az írás pillanatában.)

Ha kíváncsiak vagyunk a mi IP címünkre, megnézhetjük a https://whatismyipaddress.com/ oldalon. Az ott megjelenő IP az, amin látszódunk kívülről.

Az IP címekről és a kapcsolódó témákról vaskos könyveket lehetne írni (és írtak is sokan). Itt összefoglalok pár dolgot, amit talán érdemes tudniuk azoknak is, akik nem webfejlesztők:

  • A fent vázolt IP-t szokás IPv4-nek is hívni, mivel 4 bájtos. Ennek a párja az IPv6, ami a 6 bájtos IP-re utal. A probléma a 4 bájtos IP címmel az, hogy kb. 4 milliárd különböző értéket vehet fel, ami az IP technológia megalkotásakor egyenlő volt a végtelennel, ma viszont, amikor a világ 7 és fél milliárd lakosa nagy részének van általában nem is egy - olyan eszköze, melynek van IP címe, egyszerűen elfogyott az IP cím, vagy legalábbis nagyon szűkös. A 6 bájtos IP-ből mindenkire jut kb. egymillió, így ma ezt tartjuk kb. végtelennek. Az IPv6-ról már a '90-es években azt tanították nekünk az egyetemen, hogy hamarosan kiszorítja az IPv4-et, ez utóbbit kár megtanulni. Nos, ma (2020) még mindig az IPv4 az egyeduralkodó, IPv6 sehol nincs. (Az említett oldal elvileg kiírja az IPv6 címet is, de pl. ennek a számítógépnek nincs olyanja.)
  • A kevés IP cím kezelésére számos megoldás született. Pl. a belső alhálózatokon levő eszközök kívülről ugyanazon IP alatt látszódnak. Ilyen lehet pl. egy otthoni wifi routerre kapcsolódott eszközök IP címe.
  • A fentiből gyakorlatilag következik az is, hogy egy eszköznek több IP-je lehet, ill. van: külső IP címe (ld. fent), belső IP címe (ami a belső alhálózaton azonosítja egyértelműen), és akár még számos egyéb.
  • Vannak tipikus IP címek, amelyeket adott célra szokás használni:
    • 127.0.0.1: a helyi számítógépet jelöli (ennek az URL-je - ld. később - localhost). Pl. ha egy számítógépen indítunk egy webszervert (vagy bármilyen egyéb webes szolgáltatást), és nem közvetlenül, hanem e szerveren keresztül szeretnénk elérni, akkor ezt az IP címet használhatjuk erre a célra.
    • 192.168.*.*, ahol a *-ok helyére 0…255 tartományba eső számok írhatóak: a belső hálózati IP cím.
    • 10.*.*.*: nagyobb privát hálózat, pl. egy felhőszolgáltatáson belül. Ezeknek is van egy (ill. egy szűk tartományba eső) külső IP címük. Pl. két különböző privát hálózatban levő két eszköz közötti kapcsolat kialakítása egy olyan szintű feladat,a mi meghaladja az én személyes tudásomat.
  • Az TCP/IP technológia (a TCP egy logikai réteggel van az IP alatt) olyan, hogy a hálózati forgalmat kisebb csomagokra osztja. Ezeket a csomagokat általában nemcsak a címzett kapja meg (különösen akkor, ha a külső nincs közvetlen fizikai kapcsolatban a fogadóval), hanem mindenki, és amelyik szervert nem érinti, az vagy eldobja, vagy továbbítja. (A valóságban ennél intelligensebb a rendszer, pl. a külsők megtanulják, hogy merre érdemes tovább küldeni, és merre nem, de az egyszerűség érdekében képzeljük el így.) Az út a küldőtől a fogadóig nem determinisztikus: az egyik csomagnak lehet ez, a másiknak az az útvonala. És ez változhat is: ha az egyik belassul, akkor keres egy másik utat. Ezt tapasztalhatjuk is pl. egy Skype hívásnál: amikor nagyon belassul a kapcsolat, akkor vicces az újbóli normál sebesség beindulása: mintha a másik gyorsan mondaná össze-vissza a szótagokat. A csomagok kettőzve is megérkezhetnek, a protokollnak ezt megfelelően kell kezelnie.
  • Átjáró (gateway) és alapértelmezett átjáró (default gateway): előzőleg szó volt arról, hogy a hálózat forgalom csomagokban történik, és az útvonal nem determinisztikus. Átjáró alatt azt a számítógépet értjük, amelyen keresztül mehet a csomagunk. Ha a küldőnek nincs jobb ötlete, akkor elküldi az alapértelmezett átjárónak, melynek általában útvonalválasztó feladatköre is van. A leggyakoribb alapértelmezett átjáró, amivel minden internetet használó találkozik (még ha nem is tudatosodik benne, mert a beállítás általában automatikus) az az internet szolgáltató IP címe. A hálózat tipikus felépítése tehát a következő:
  • Szó volt IP tartományról, pl. 192.168.*.*. Itt a bal oldali bitek a fixek, és a jobb oldaliak adják a tartomány terjedelmét. Ennek a szokásos jelölése a következő: nullázzuk ki a tartományon belüli biteket, és egy per jellel írjuk mögé a bal oldali fix bitek számát, pl. 192.168.0.0/16, vagy pl. 192.168.1.0/24 (ez esetben a tartomány mérete 256, és az első 24 bit a fix).
  • Szorosan kapcsolódó fogalom az alhálózat maszk (subnet mask): itt egyesek jelöli a fix értékeket, 0-k pedig a tartományt, pl. 255.255.255.0 egy 256 hosszú IP tartományt jelöl.

A hálózatokkal kapcsolatos ismereteim nekem is gyerekcipőben járnak (elképzelhető, hogy írtam butaságot is; ez esetben szívesen veszem a javítást), és tervbe van véve a témában való elmélyülés, és természetesen a megszerzett ismereteknek a honlapomon történő dokumentálása.

URL

A világhálón jelen levő számítógépek egyértelmű és kizárólagos azonosítása IP cím segítségével történik. Ugyanakkor a legritkább esetben használjuk közvetlenül az IP címet: ha megnyitunk egy oldalt egy böngészőben, akkor általában egy www.[valami].com, www.[valami].hu vagy hasonló, az IP címnél könnyebben megjegyezhető valami látható. Ezt a címet URL-nek nevezzük, ami az Uniform Service Locator (egységes erőforrás helymeghatározó) rövidítése. A háttérben ez mindig IP címre fordítódik.

Az URL-IP fordításért az ún. DNS (Domain Name System, tartománynévrendszer) a felelős. Ez hierarchikus szervezésű: a legfelső szint az országot (pl. .hu: Magyarország) vagy fő tevékenységet (pl. .com: kereskedelmi) jelöl. Mindegyiknek legfelső szintnek van további saját DNS feloldója. Tehát ha valaki bárhol a világon megpróbálja megnyitni a faragocsaba.hu weboldalt, akkor általában a saját internetszolgáltatójának a DNS-e tudni fogja, hogy melyik szerverhez kell fordulnia a .hu alá regisztrált szerverek feloldásához (de természetesen létezik egy abszolút központi DNS szerver, ahova a legfelső domain neveket regisztrálják). A gyakrabban használt domain nevek IP címét a DNS szerverek általában el szokták tárolni, hogy ne kelljen naponta sok milliószor végrehajtani ugyanazt a lekérdezést; ilyenkor persze változás esetén eltelhet pár óra, mire mindenhol aktualizálódik az új érték.

Az URL viszont több annál, mint egy weboldal címének átfordítása IP-vé. Az URL tartalmazza a protokollt is pl. http: vagy https:, adott esetben a portot, azon belül az erőforrást, és paramétereket is, pl. http://www.mytestdomain.com:8080/helloworld?name=Csaba. És a protokoll számos egyéb lehet, pl. file: a saját fájlrendszeren található fájlra hivatkozik (pl. file:/D:/teszt.txt).

Az URL-lel kapcsolatos fogalom még az URI, Uniform Resource Identifier, azaz egységes erőforrás-azonosító. Az URI általánosabb fogalom mint az URL,tehát tartalmazza az összes URL-t, és még sok egyebet. Egy XML-en belülie Xpath hivatkozás, egy könyv ISBN azonosítója, vagy egy mailto: hivatkozás szintén URI, de nem URL.

HTML

A HTML a Hyper Text Markup Language rövidítése. Ez egy szabvány, amiben a weboldalak készülnek. Ilyen formában készülnek a szövegek, az alap formázások, linkek, képek stb. Fontos tudnunk, hogy a weben mindennek az alapja a HTML, azaz a ma ismert web minőségéhez képest egy rendkívül egyszerű és buta leíró nyelv. Ez nagyon sok problémának a gyökere. Egy ilyen leíró nyelvtől túl nagy csodát nem várhatunk, bármilyen interakcióhoz külső rendszerre van szükség, amire a HTML-ből hivatkozunk. Ilyen pl. a JavaScript, az Applet vagy a Flash, ill. számos más egyéb. A HTML-nem nincs ráhatása arra, hogy mi történik "belül".

Tehát mivel a HTML alapból nagyon buta, az igény az interaktív weboldalak iránt pedig megnőtt, számos külső, egymástól független technológia jelent meg, ami viszont komoly biztonsági kockázatokat jelentett. Ugyanis ahhoz, hogy az ilyen tartalmat tartalmazó oldalak működjenek, a böngészőknek meg kellett engedniük azt, hogy külső gyártó beépülőjét telepítsék és használják, amire a böngészőnek nincs ráhatása. Az pedig már böngészőfüggő, hogy melyik hogyan reagál erre a veszélyre: pl. a Google Chrome letiltott számos külső technológiát, más böngészők pedig megnehezítették a használatukat azzal, hogy külön fel kell telepíteni a beépülőt, és engedélyezni is kell.

Márpedig az egységsugarú felhasználó nem szeretne semmit sem telepíteni, sem beállítani, egyszerűen csak meg szeretné nyitni a weboldalt. Ebből a feszültségből jött létre a HTML5 szabvány. Ez utóbbi ugyanis elvileg tartalmaz olyan, elsősorban multimédiás lehetőségeket, de más újításokat is, ami elvben feleslegessé teszi a többi technológia használatát. Azzal, hogy a fontosabb böngészők korlátozzák vagy tiltják a korábbi megoldásokat, a felelősség a felhasználó milliárdjairól a weboldalakat készítő cégek ezreire tolódik, hogy lecseréljék a régi rendszereiket HTML5-re.

Az átállás azonban nem zökkenőmentes:

  • A HTML egy szabvány, és többé-kevésbé kompatibilisnek kell maradnia az elődeivel. Tehát ha volt mondjuk az 1990-es években egy szerencsétlen döntés, akkor a szabvány megalkotóinak döntenie kellett aközött, hogy megtartják, és tovább cipelik a terhet, vagy megszabadulnak tőle, de akkor nem lesz kompatibilis a korábbi verziókkal. Hol így, hol úgy döntöttek.
  • A HTML csak egy szabvány, amit a böngészők elvileg támogatnak, vagy nem. Egyes böngészők előre szaladtak, mások külön utakat jártak, és a szabvány készítőinek figyelembe kellett venni a pillanatnyi valóságot. A tapasztalat szerint pl. az Internet Explorer mindig is kilógott a sorból, az valahogy sosem úgy támogatta a szabványt, mint a többi.
  • Már csak amiatt sem érthettek el túlzottan a pillanatnyi realitástól, mert figyelembe kell venni azt, hogy a földön több milliárd ember használ böngészőt, esetleg több tíz milliárd formában (asztali számítógépen, laptopon, tableten, okostelefonon, egyéb okoseszközökön, esetenként többet); ezek fel vannak telepítve és használatban vannak, a frissítés pedig ezen a több tízmilliárd esetben nem megy egyik pillanatról a másikra.

A HTML5 világban érdemes megismerkedni a szabvány adta lehetőségekkel, és a nulláról készített interaktív weboldalakat ebben a formában elkészíteni, az interakciót JavaScripttel megvalósítva. A JavaScriptet ugyanis nem lehet nélkülözni, mivel a HTML5 továbbra se programozási nyelv.

CSS

A HTML mellett gyakran megjelenik a CSS betűszó, erre és térjünk ki pár gondolat erejéig: ez a Cascading Style Sheets rövidítése, és - ahogy a nevéből is kikövetkeztethető - az oldalak stílusait lehet vele megadni. Ez már weboldal készítési részlet, de azért szerintem felhasználóként is érdemes tudni, hogy a HTML elsősorban a logikai formázást támogatja (tehát pl. azt mondjuk meg, hogy ez legyen cím, az folyószöveg), a CSS pedig a stílust (pl. azt, hogy a cím legyen piros, 14-es betűmérettel, a folyószöveg pedig fekete, 10-es betűmérettel). A valóság sajnos sokszor nem ennyire vegytiszta, de ideális esetben a HTML csak a tartalmat határozza meg, a CSS pedig 100%-ban meghatározza a kinézetet. Mivel mindig a HTML az alapja a weboldalaknak, a CSS-re HTML-ből kell hivatkozni.

A CSS tehát a HTML-lel szorosan összefüggő, ám attól mégis független szabvány, ami szintén egy leíró nyelv, és ezek támogatását ugyanúgy meg kell valósítani az egyes böngészőkben, mint a HTML-ét.

JavaScript

Önmagában a HTML-től és a CSS-től még nem várhatunk komoly interakciót. Kezdetben olyan interakciós lehetőségek voltak, mint pl. egy animációs gif, egy formanyomtatvány vagy a linkek. A HTML5-ben - ahogy volt róla szó - megjelentek a multimédiás lehetőségek, és pl. egy filmet is be lehet helyezni, tehát néhány igen gyakori használati esetet HTML szabvány szinten is lefedtek. Általános esetben viszont továbbra is nélkülözhetetlen a JavaScript használata, ami a böngészőben futó program. Neve ellenére semmi köze sincs a Java-hoz.

A JavaScript egy teljes értékű programozási nyelv: megtalálhatóak benne a szokásos programozási struktúrák (függvények, változók, feltételkezelés, ciklus stb.), segítségével át lehet alakítani a teljes HTML dokumentumot (létre lehet hozni új komponenseket, módosítani lehet meglevőeket és törölni is lehet belőle). Igen gazdag a külső könyvtár támogatottság (jQuery, ExtJS, AngularJS, VueJS stb.), ami segíti a fejlesztőket a minél interaktívabb weboldalak elkészítésében.

Fejlesztők körében gyakori betűszó az AJAX, amivel esetleg nem fejlesztő is találkozhatott már: ez az Asynchronous JavaScript And XML rövidítése. Ez egy JavaScript-re épülő programozási technika. Arról már volt szó, hogy mivel a JavaScript alkalmas a weboldalak módosítására, adott esemény hatására (ami lehet egy felhasználói interakció, de akár egy időzítő is) a háttérben lekérdezi az adatokat, majd módosítja a weboldal tartalmát, azt a hatást keltve, mintha egy igazi asztali alkalmazásról lenne szó. Pedig továbbra is egy böngészőben futó, végső soron "buta" HZML-ről van szó! A betűszó részei:

  • Asynchronous: a dolog aszinkron módon történik. Ennek az ellentettje a klasszikus megoldás: a tartalom addig nem változik, amíg a felhasználó explicit rá nem kattint a frissítést kiváltó gombra, aminek következtében teljesen újratöltődik az oldal. Talán nem a legmegfelelőbb szó itt az aszinkron, amivel azt fejezzük ki, hogy nem a vázolt, úgymond szinkron don történik a frissítés.
  • JavaScript: a technológia, ami megvalósítja.
  • XML: amikor a módszert kitalálták, az adatokat XML formában kérdezte le a JavaScript, és az eredményen végiglépkedve alakította át HTML-lé. Ma már nem feltétlenül XML az adathordozás formátuma, hanem inkább JSON, de a megnevezésben megmaradt az XMLáre utaló X.

Applet

Az Applet Java-ban írt alkalmazás, ami a böngészőben fut. Általában a böngészők alapból nem támogatják, sőt, az írás pillanatában inkább már lehetővé sem teszik, de ha mégis, a Java beépülőt külön fel kell telepíteni. A megfelelő hivatkozáshoz a HTML-ben az <applet> tag-et kell használni.

Az egykor ígéretes technológia csillaga leáldozóban van, helyét átvette a Flash, majd később a HTML5.

Flash

Az Applet kicsit a technológia "megerőszakolása": egy alapvetően nem webes célra kitalált programozási nyelv webes célra történő alkalmazása. A Flash ezzel szemben kifejezetten webes célra lett kifejlesztve. A támogatottsága jóval szélesebb körű: elvileg ehhez is beépülő kell (https://get.adobe.com/flashplayer/), de számos böngésző alapból tartalmazza. Általában Flash-ben készültek a mozgó bannerek, reklámok, vagy a böngészőben játszható egyszerűbb játékok. Az írás pillanatában ennek is leáldozóban van a csillaga, de még jóval elterjedtebb mint az Applet.

Süti

A böngészés maga alapvetően állapotmentes. Ez azt jelenti, hogy mindig a böngésző kezdeményezi az adatforgalmat, elküldi a kérést, a szerver elküldi a választ, és a következő interakció teljesen független a korábbiaktól. Azonban sok esetben szükség van arra, hogy egy korábbi állapot megmaradjon. Gondoljunk egy webshopra: ha beléptünk, akkor a következő lépésben tudni szeretné a szerver, hogy be vagyunk lépve. Ha vettünk valamit, és folytatjuk a vásárlást, akkor az az elvárt viselkedés, hogy nem felejtse el a szerver, hogy mit tettünk a kosarunkba. Majd a fizetésnél is szükség van arra, hogy kik vagyunk és mit vásároltunk. A példa lehet, hogy erőltetett, de annak érzékeltetésére szerintem megfelelő, hogy a böngészés során mégis szükség van adatok rövidebb-hosszabb ideig történő tárolására és a szerverrel történő újbóli megosztásra. Erre a célra találták ki az ún. sütiket (angolul cookie). Ezek valójában kulcs-érték párok, amik a böngészőben tárolódnak, és a későbbi lekérdezések során a böngésző meta információként elküldni a szervernek. A süti szerverfüggő, tehát csak azt a sütit küldi a böngésző a szervernek, amit ő maga tároltatott el. A szerver ennek megfelelően tudja alakítani a válaszát.

A süti alkalmas arra, hogy kövesse a tevékenységünket. Azon a nyilvánvaló túl, hogy a szerver tudni fogja, milyen gyakran és a nap mely szakában látogatunk az oldalára, el tudja menteni a GPS pozíciónkat, vagy azt, hogy milyen reklámra kattintottunk, akikor az oldalt böngésztük, a példát lehetne sorolni, és egy egész komoly profilt tud felépíteni. Ezen kívül egy-egy oldalnak lehetnek beépülőik. Pl. ha egy A oldalnak van egy B beépülője, és megnyitom az A oldalt, akkor a B oldal is értesül arról, hogy ekkor és ekkor megnyitottam az A oldalt, és ez utóbbiról általában nem is tudunk.

A süti tehát kétélű fegyver: egyrészt nélkülözhetetlen a modern böngészéshez, másrészt talán jogosan érezzük azt, hogy kicsúszik a kezünk közül az irányítás. És mindennek van egy bosszantó mellékhatása: minden egyes meglátogatott oldalon jóvá kell hagynunk a sütiket; nem tudom, hogy hogy van ezzel de engem ez nagyon bosszant (figyelembe véve azt, hogy számos egyéb műveletet is végre kell hajtani, mire olvasni tudunk a tényleges tartalmat).

VPN

A VPN Virtual Private Network (virtuális magánhálózat) rövidítése. Amint arról már volt szó a böngészés dióhéjban az alábbi: a felhasználó az internetszolgáltatótól kap egy IP címet, és azon keresztül elküldi a kérést a szervernek, ami a választ ugyancsak a szolgáltatón keresztül küldi. Noha a tartalom általában titkosított (ld. https), az internetszolgáltató nyilván látja, hogy milyen szerverről mit töltöttünk le. Lehet, hogy ezt nem szeretnénk. És most nem feltétlenül a saját internetszolgáltatónkról beszélünk, hanem mondjuk egy nyilvános wifi hálózatról.

Az is előfordulhat, hogy bizonyos tartalom csak bizonyos IP tartományból érhető el (pl. vállalati intranet), és az internet szolgáltató a kívánt IP tartományon kívül eső IP címet ad számunkra.

Mindkét problémára megoldást a VPN jelenti. Technikailag ez azt jelenti, hogy bejelentkezünk egy szerverre, és ettől kezdve minden azon a szerveren keresztül történik. Az internetszolgáltató csak annyit fog látni, hogy a teljes adatforgalomra egy VPN szolgáltatót használunk (hogy melyiket, azt jó eséllyel tudja). Ezen kívül az IP címünk is megváltozik; a legtöbb VPN szolgáltató pl. lehetővé teszi azt, hogy megadjunk országot, ahonnan szeretnénk, hogy kívülről látszódjunk. Céges VPN esetén olyan IP címet kapunk, amit a rendszer belső hálózatként fog érzékelni, így hozzáférésünk lesz pl. az interanethez.

Publikus VPN szolgáltatók általában azonosító/jelszó párost alkalmaznak. Ez az egyén szempontjából lehet elég biztonságos, egy cég szempontjából viszont nem, így az azonosításnak kifejezetten a VPN-re kifejlesztett módját tudjuk használni: a tokent. Erről már volt szó az azonosítósról szóló szakaszban.

Ha a célunk a teljes anonimitás, akkor természetesen olyan VPN szolgáltatót célszerű választanunk, amely garantálja azt, hogy nem naplózza a tevékenységet. (Itt most ne arra gondoljunk, hogy megnézzük a Facebook értesítéseinket egy publikus hálózaton, hanem olyan politikai tevékenységet folytatunk egy diktatúrában, aminek akár halálbüntetés is lehet a következménye.)

A VPN szolgáltatás általában fizetős. Az egyik legnépszerűbb és legjobb VPN szolgáltató a NordVPN (https://nordvpn.com/). Ott a kipróbálás úgy ingyenes, hogy ki kell fizetni, és ha nem vagyunk elégedettek, akkor visszafizetik. Ténylegesen ingyenes kipróbálási lehetőséget nyújt a ProtonVPN (https://protonvpn.com/).

A VPN-ről szerzett ismereteim személyes tapasztalaton túl az alábbi oldalról származnak: https://www.vpnmentor.com/blog/vpns-101-vpnmentors-vpn-guide-newbies/; ezt javaslom én is a téma iránt mélyebben érdeklődőknek.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License