A Firefoxból is eltűnik az FTP-támogatás

A Google után a Mozilla is meghozta a döntést.

Michal Novotny, a szervezet egyik fejlesztője jelentette be, hogy a jövőben eltűnik az FTP-támogatás a Firefoxból. A szakember hozzátette, hogy egy nem biztonságos protokollról van szó és semmi sem indokolja, hogy valaki a különböző adatok letöltésére a jövőben az FTP-t használja a HTTPS helyett. Azt sem szabad figyelmen kívül hagyni, hogy a kapcsolódó programkód rendkívül öreg, így annak foltozgatása egyre nehezebben valósítható meg és egyre időigényesebb. A múltban számos biztonsági hibát találtak a kódban.

Az FTP-támogatás kikapcsolása a böngésző 77-es verziójában valósulhat meg, amely várhatóan júniusban jelenik meg. Bár a funkciót deaktiválják, a kapcsolódó programkód eleinte még megtalálható lesz a szoftverben, vagyis a felhasználóknak lehetőségük nyílik majd a támogatás újbóli bekapcsolására.

Tavaly a Google is jelezte, hogy száműzi az FTP-támogatást a Chrome böngészőből. A társaság azzal indokolta a lépést, hogy a funkciót már csupán néhány internetező, konkrétan a felhasználók 0,1 százaléka használja, továbbá csak a 0,03 százalékuk tölt le valamit a segítségével. A Chrome várhatóan a 82.0-s kiadástól nem támogatja az FTP protokollt.

Hozzászólások

A témához csak regisztrált és bejelentkezett látogatók szólhatnak hozzá!
Bejelentkezéshez klikk ide
(Regisztráció a fórum nyitóoldalán)
  • kvp #6
    Ha webszerverrol akarjak elerhetove tenni egy konyvtar letolteset, akkor raknak egy download directory link-et a listaba es egyetlen mozdulattal le lehet huzni az egeszet. Ha nem raknak ilyet akkor valoszinuleg nem szeretne a publikalo, hogy ezt tegyek az olvasok.

    Mindezektol fuggetlenul, a regi protokollok azert mukodnek jol, mert egyszeruek. Viszont biztonsagi szempontbol nem igazan jok, a mai vilagban inkabb mar veszelyesek az atlagos emberekre.

    Arrol nem beszelve, hogy attol, hogy a chrome vagy a firefox nem tamogatja, meg van 1001 ingyenes, nyilt forraskodu es direkt az adott celra keszitett kliens. Ftp-hez is ott vannak a megbizhato es jo ftp kliensek es szerverek, nem kell egy bongeszobe, ami egy http kilens belezsufolni azt ami nem oda valo. Ezert nincs a bongeszokben manapsag mar email, telnet vagy bittorrent, esetleg uucp vagy gopher kliens. (egy idoben mindez benne volt nemelyik bongeszoben)

    Szoval svajci bicska helyett jobb egy celprgoramot kesziteni mindegyik feladatra es akkor mindenki olyan szerszamkeszletet rak ossze amilyet szeretne. Ez lenne a unix rendszerek egyik alapelve.

    ps: A gopher az felig publikus ftp, felig http volt, de igazabol egyik sem es egy idoben minden fontosabb bongeszo kezelte. Az uucp egy nagyon hatekony file atviteli rendszer volt, alapvetoen teljes message/file repository-k egyszeru es gyors replikalasara lett kitalalva es ezen mentek a regi newsgroup-ok, amik a web elotti kor kozossegi oldalai voltak. (anno meg 2*24 ora volt a leggyorsabb valaszido Budapest es az USA nyugati partja kozott, szoval eleg lassuak voltak a flame war-ok, egy ilyen vegen huzta fel annyira magat Linus hogy nekiallt megirni a linux-ot)
  • Caro #5
    Tisztában vagyok ezekkel, ugyanakkor továbbra is: ha pl. egy könyvtárat le akarsz tölteni magadnak, és az webszerveren van fent, megteheted ugyan, de szívás lesz.
    wget recursive opcióval, no-parent, stb kapcsoló, mivel egy html-ben kiadott fájl lista semmilyen szabványt nem követ.
    Egy ftp az igen, mivel FILE TRANSFER PROTOCOL a neve. Nyilván nem ezen kell szupertitkos dolgokat kommunikálni, de fájlok hostolására a mai napig tökéletes lenne. Amikor azokat nem kell elrejteni.

    Igény pedig van erre a funkcionalitásra, elég megnézni, hogy a google drive, nextcloud, stb. mit küzdöttek azért, hogy pl. drag-n-drop fájlfeltöltést megoldják. Igaz, ott már sokszor kellene a titkosítás.

    Nekem az utóbbi időben egyfajta hobbim lett a régi számítógépek összerakása. Érdekes megfigyelni, hogy az összes titkosítatlan protokoll abból az időből kompatibilis a mai gépekkel. Telnet, ftp, http működnek.
    Semmilyen titkosított protokollt nem lehet viszont velük összehozni. SSH, HTTPS egyszerűen annyit változtak, hogy soha nem fognak együttműködni, mindegyikről előbb-utóbb kiderült, hogy lyukasak.

    Persze, ez réteg igény, de ha nem nagyon fáj senkinek a kód, akkor minek kell kitörölni? És sajnos ma ez divat lett, holott a mai szoftver komplexitásnak elenyésző részét adják ezek a régi protokollok, de mégis ott vannak, HA valakinek kell a kompatibilitás. Dolgoztam én pár éve olyan helyen, ahol ipari rendszerek alsó szintű szoftvere még mindig DOS volt. Milyen jól jött ott, hogy a DOS-ra lehetett tenni FTP szervert, és fájlokat másolni rá. Semmilyen hálózatra nem volt rákötve a DOS-os gép, de mégsem kellett külön utakat járni a fájlok másolására.

    Az IPv6-ot azért említettem, mert sajnos az utóbbi időben minden a cloud felé tolódott a kényelem miatt. Mert a NAT-ok miatt gyakorlatilag nem tudunk két gép között közvetlen kapcsolatot létesíteni. Ezért esett ki az UDP is a kosárból, mert sok tűzfal nem engedi ki az UDP forgalmat. IPv6 mellett ezek a problémák megoldódhatnak, és véget érhet az az áldatlan állapot, hogy egy videohívást úgy tudunk lebonyolítani, hogy a világ másik felére kell átküldeni a stream-et.
  • kvp #4
    Az ftp olyan mint a telnet. Titkositatlan es meg az ellen sem ved, hogy valaki a elvegye elolunk az eppen letolteni szandekozott file-t. (ehhez eleg egy jokor kiadott netcat parancs egy masik geprol) Nem biztonsagos es nehezen hasznalhato tuzfalakon at. A firefox is joreszt csak az anonim (publikus) passziv letoltest tudta uzembiztosan kezelni. Persze nem a https az alternativaja, hanem az scp vagy az sftp. Ezeket siman belerakhatnak a bongeszobe, de mivel egy bongeszo alapvetoen nem telnet, ssh vagy ftp kilens, hanem http/https, ezert nem meglepo, ha nem akarnak ezzel szivni. A https egyebkent akkor alternativaja az ftp-nek, amikor publikus file-okat akarunk letolteni egy weboldalrol. Regebben a weboldalak ftp-s letoltesi linkeket tartalmaztak, ma mar jellemzoen ezek a letoltheto file-ok is a webszerveren vannak fent.

    Vannak rendes rlogin/telnet/ssh/ftp/sftp/scp kliensek, amik viszont ezeket a protokollokat kezelik viszonylag jol.

    ps: IPv6-tal kapcsolatban annyi info, hogy a legtobb mobilnetes kapcsolat mar itthon is azt hasznal, mert a szolgaltatok reges regen kifogytak a v4-es cimekbol, meg a nat-oltakbol is. NAT jellemzoen mar csak akkor kell amikor egy ipv6-os keszulek csak ipv4-es cimmel rendelkezo szervert akar elerni. Az ipv6 egyebkent semmit nem valtoztatott a folotte futo protokollokon, ugyanugy a regi tcp megy felette mint eddig.

    Media stream-elesre https-t csak akkor hasznalnak, ha elore buffer-elt tartalomrol van szo, tehat a gep letolti a stream-et. Ilyen pl. a youtube. Rendes stream-ek eseten (pl. video vagy audio hivasok) udp-n megy minden adat. (az UDP-s youtube stream olyan lenne, amibe nem tud valaki azonnal beletekerni vagy megallitani, tovabba halozati ingadozasok eseten kimaradnana a kep meg a hang, igy inkabb bufferelnek https-en es all meg a video amig helyre nem all a forgalom, minthogy percenkent kimaradjon 1-1 masodperc a videobol, aztan 10 masodperc legyen amig helyreall a kep integritasa, a youtuble egy elore felvett video szoltaltatas, nem realtime video chat)
  • gergely1991 #3
    Ezek után biztos lesz bővítmény ami az ftp-t "visszakapcsolja",
  • Tetsuo #2
    Dehát mér eljött az IPv6 ideje, nem?
  • Caro #1
    Nem dicsőíteném az FTP-t, megvannak a maga bajai, de HTTP-n egy szabványos fájl-listát sem lehet lekérni.

    Ezen kívül még a feltöltést is elég nyögvenyelősen támogatja. Persze, van PUT request, csak gyakorlatilag senki sem használja.

    A régi rendszerekkel való kompatibilitás pedig mindig ott van. Igaz, amíg a midnight commander-ből nem kerül ki az FTP támogatás, addig én elvagyok :)

    Azt eléggé sajnálatosnak tartom, hogy gyakorlatilag MINDEN adatot most már HTTPS-re terelnek, pedig a protokoll nagyon nem való mindenre. Olyan dolgokat is, amiket pl. UDP-n kellene küldeni (videostream pl.).

    De majd egyszer talán eljön az IPv6 ideje, és ezek megoldódnak... meg persze lesz egy csomó új kihívás is.