A Chromium fokozatosan kivezeti az FTP támogatást

 ( pehsa | 2018. december 19., szerda - 11:12 )

A Chrome 72 Beta-tól kezdve fokozatosan kivezeti az FTP támogatást. Jelen állapot szerint a struktúrát még megjeleníti, de az FTP-n található fájlokat már nem fogja betölteni megjelenítésre, hanem egyből letöltésre ajánlja fel őket.

A következő verzióktól kezdve pedig még jobban kivonja a támogatást, arra hivatkozva, hogy nem eléggé biztonságos a protokoll.

https://blog.chromium.org/2018/12/chrome-72-beta-public-class-fields-user.html

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ezt most tényleg nem értem. Mennyivel kevésbé biztonságos az ftp mint az ssl nélküli http? Mennyivel vagyunk beljebb, ha a böngésző nem megjeleníti, hanem elmenti a tartalmat, a user úgyis rá fog kattintani a lemenett fájlra. Amúgy jó ötlet, hogy rögtön letölti és nem megjeleníti, hiszen az ftp file transfer protocoll, azaz úgyis fájlt akartam transzferelni :-).

Szerintem ebben benne van a valasz: https://www.kernel.org/shutting-down-ftp-services.html

- The protocol is inefficient and requires adding awkward kludges to firewalls and load balancing daemons
- FTP servers have no support for caching or accelerators, which has significant performance impacts
- Most software implementations have stagnated and see infrequent updates

Nem mintha bajom lenne az FTP-vel.

-----
"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

+1, kihalófélben van, és jó okkal.

Az Archive Team speciel három éve folyamatosan archiválgatja a publikus FTP site-okat, mert sorban zárnak be.

https://www.archiveteam.org/index.php?title=FTP

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

AZ OK, hogy az ftp-nek az az ötlete, hogy legyen külön adat és parancs tcp kapcsolat nem Nobel díjas ötlet és emiatt ki kell halnia ezzel semmi gond. A szerver oldalon szüntesse meg akinek útjában van, de miért a kliens korlátozza a supportot. Ennek csak egy racionális okát látom, hogy nem akarják a kliens oldali kódban az ismert biztonsági hibákat kijavítani inkább azt mondják, hogy a protokoll nem biztonságos, holott csak éppen kihalóban van.

ha FTP-t szeretnél használni, használj FTP klienst. Most arról van szó, hogy egy böngészőből kukáznak egy totálisan más protokolt.

És minden egyes fájlra külön kapcsolatot nyit és zár be, ha jól emlékszem :)

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Nem azért nem biztonságos, mert tele van ismert hibákkal az implementáció, hanem maga a koncepció nem biztonságos. Ha megváltoztatnák a koncepciót, akkor az már nem ftp lenne.

Ftp-t pedig még mindig rengeteg helyen lehet találni. Nem az a lényeg, hogy hol nem használják, hanem az, hogy ahol használják, ott a felhasználók által kényszerítsék a lecserélését.
Mert hiába van bármilyen újabb technológia, mindig a lustaság és a spórolás az első, hogy amíg működik, addig nem cserélik le a kiszolgálókon (a bajai ellenére).
De ha az ügyfelek elkezdenek panaszkodi, vagy várható, hogy az ügyfelek hamarosan elkezdenek panaszkodni, akkor nagy duzzogva csak nekifognak alternatíva keresésének.

Bizonyos szempontból ez a piaci részesedéssel való visszaélés. De vannak dolgok, amiben nem működik a demokrácia, hogy a leglustábbnak is ugyanannyit ér a szava. És mielőtt valaki kitalálja, hogy dehát ez plusz költséget okoz a kiszolgáló oldalon, hát az már régen el kellett volna költeni, csak tojtak a biztonságra.

Hol kevésbé biztonságos az ftp protokoll mint a http - mindkettőnek a titkosítás nélküli változatát nézzük.
Mindkettőnél titkosítatlan jelszavak utaznak tcp kapcsolatban. Az persze tény, hogy az ftp parancs és adatcsatorna szétválasztása ma már - nagy sávszélesség, nagy késleltetés kis csomagvesztés - nem hatékony, de nem is erre a hálózatra lett tervezve hanem egy kis sávszélességű nagy csomagvesztéses Internetre. Ha a megfelelő IP flageket bebillented és a routerek figyelembe veszik a két csatorna akár másfele is routolódhat pl. a parancs csatorna földi kis sávszélességű kis válaszidejű, de drága vonalon, míg az adatcsatorna műholdas erősen aszimmetrikus nagy késleltetésű hálózat felé.
Ma nyilván ezek nem relevánsak, tehát maradnak a hátrányai, azaz kihal, de ezt ne fogjuk a biztonságra.

A http visszaszorítása is céljuk
https://www.hwsw.hu/hirek/59129/http-google-biztonsag-chrome-bongeszo-site-isolation.html

a többi meg csak összeesküvés elmélet. Egy hót primitív protokol imlementációja mögé ne képzeljünk már öszeesküvést, hogy nem akarják a biztonsági hibáit kezelni. Nem tudom mire gondolsz a csomagvesztéses internettel, azon felül, hogy a tcp réteg megpróbálja újrakérni a vesztett csomagokat a protokol nem valószínű, hogy támogat bármilyen extra csomagvesztés elleni védelmet.

Műholdas internetet sem sok ember látott akkoriban, amikor bármit számított volna ez, amit írsz. Bár akkor sem, hiszen a parancs csatornán csak pár bájtos utasítások mennek. Bár igaz, nem neteztem a dzsungelből műholdas betárcsázós internettel a 70es években, szóval nem tudhatom :D

A kihalással meg az a baj, hogy még nagy cégeknél sem feltétlen hal ki, amíg nincsenek rákényszerítve, mert sóher és lusta a management. Ez többet számít, mint a biztonság.

Nemcsak megpróbálja újrakérni a tcp hanem addig kéri újra még meg nem kapja. Ez nem best effort elven működik mint az udp :)

Arra akartam volna rámutatni, hogy a protokollnak nincsenek nagyobb beépített biztonsági hibái, mint a http-nek. Ha az a baj, hogy nem titkosított az ftp, a https-hez hasonlóan van tls-sel turbózott ftps is. Figyelmedbe ajánlom az IP differentiated services szolgáltatását (https://en.wikipedia.org/wiki/Differentiated_services) ami alapján a jobb routing protokollok (legegyszerűbb pl. az OSPF) különböző feszítőfákat tudnak az egyes típusú szolgáltatásokhoz készíteni, azaz a különböző típusú csomagok más úton közlekedhetnek. Okos dolog például a voip forgalmat és a bulk file letöltést nem ugyanarra küldeni, mert a file transfer esetén optimális nagy csomagméret egy sávszélességben szűk keresztmetszet esetében megöli a voip forgalom nagyon gyakori kicsi csomagjainak a késleltését (mielőtt valaki írná tudom, hogy a differentiated services sokat segít ezen,feltéve hogy olyan router van a szűk keresztmetszet két oldalán, ami figyelembe veszi). Tehát a hálózat teljes áteresztőképessége szempontjából az ftp egy jó protokoll. Az más kérdés, hogy ma egyre kevésbé fontos szempont ez, helyette fontossá vált a cache és reverse proxy használata aminek a szempontjából viszont az ftp nem jó. Az IPv4 elfogyása miatt orrba szájba NAT szempontjából az ftp szintén nagyon barátságtalan.
Ha le akarjuk építeni ám tegyük, de ne olyan indokkal, hogy nem biztonságos. A biztonsági hivatkozást egyes implementációk esetén tudom elfogadni. Ilyenkor lehet az is racionális gazdasági döntés, hogy nem javítjuk, hanem kidobjuk az egészet. Ezt is lehet, de akkor mondják ezt - bőven elegem van a politikusok esetében a hazudozásból - szerintem az IT szakma van annyira felnőtt, hogy kibírjuk az igazságot is.
Mellékszál: Lehet persze, hogy azért bosszant jobban a mellébeszélés, mert ehhez értek és emiatt átlátom a helyzetet és nem szeretem, ha hülyére vesznek. Belegondolni is rossz, hogy hányszor vesznek hülyére olyan dolgokban, amihez kevésbé értek.

"Let's face it -- while kinda neat and convenient, offering a public NFS/CIFS server was a Pretty Bad Idea"

De lokálisan továbbra sem kellene halálra ítélni az ftp-t. Ahogy az említett public NFS/CIFS sem volt túl jó ötlet, de lokális hálózaton máig van helye.

Ki akarják dobni a kódból az ftp-vel foglalkozó részt, és ideológiát keresnek mellé, akár igaz, akár nem. Az userek 99%át úgyse érdekli a téma.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Igazad van. Pont ezt kifogásoltam.

Cégnél mai napig futtatunk ftp szervert, de ahogy nézem, még jó sokáig fogunk is. Total commander felcsap, és már lehet is használni.

<reklám on>
És még a MultiCommander is kezeli :))

A rövidneve pedig hasonlít a Midnight Commander-ére :))

Kiváltottam vele a nem teljesen legális 1-2-3 freeware Totalt kompromisszum nélkül.
Szerintem érdemtelenül nem ismert, bár az első beállítással
el lehet molyolni egy fél napot, mire kézreáll, utána viszont
kimásolva portableként még frissíthető is...
<reklám off>

Bocs az off-ért...

Mukk

Aki/ahol 10+ éve használjàk, ott ki kéne csengetni a 30-40 EUR számlát Ghisler-nek.
--

+1, bár gondolom a tisztelt 1-2-3 freeware userek sem kapnak fizetést a munkájukért, szóval nem elvárható, hogy ők is fizessenek máséért

Magánemberként, otthonra vettem meg.
Igaz én már 20 éve használom.
--

Vagy Double Commander

+1

A Double Commandert én is jobban ajánlom, multiplatformos, és tudásban is ez közelíti meg legjobban a TC-t. Ahogy nézem, ez a MultiCommander nem is TC klón, inkább kétpanelesített Intéző, és csak Windows only.


No keyboard detected... Press F1 to run the SETUP

+1

Én is megelégedéssel használom, TC tiltott a cégnél, arról váltottam.

A lustaságon kívül mi hiányzik ahhoz, hogy sftp-re váltsatok?
Ha publikus irányból is elérhető, irodán kívül is rákapcsolódtok, akkor kérdés, hogy ügyféladatokat is mozgattok-e. Betartjátok-e a gdpr szabályokat?

Az sftp támogatás egyáltalán van Chrome-ban?

Nálunk win10 -ben sincs. Régen simán beírtam a filekezelőbe hogy sftp://user@host és kérte a jelszót, most meg error.

Majd ha a tc-ben lesz by default sftp plugin, akkor. Most ctrl+f, és kész. És ez nem az én döntésem, hanem a kollegáké, akik használják.
Amúgy ja, elég komoly user adatok vannak nálunk, azt a 4 betűset meg magasról lesz@rjuk. Én még betarthatnám, de a kollegák úgyse fogják. User adat pedig csak átmenetileg van, ha valamit az adatbázisám tesztelni kell az irodába, utána kuka, ezt viszont betartjuk.

Minden jót tönkre kell tenni, miért lenne ez alól kivétel pont az ftp?
Azzal nincs baj, hogy egy hülye elkezd valami ökörséget, a baj majd akkor lesz, ha a többi is követi példáját.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

De nem az FTP protokollt fogják betiltani - bár már eléggé meghaladott -, csak a chrome nem fogja támogatni. Nem nagy veszteség, kétlem hogy a chrome böngésző egy elterjedt FTP kliens lenne.

Így van. A böngészők amúgy sem nagyon alkalmasak FTP kliensnek. Az FTP élni fog tovább, de tényleg elvárható, hogy public szolgáltatások ne használják. Én pl. LAN-on előszeretettel használok FTP-t, ha különböző OS-ek között nem akarok SMB megosztással és NFS-sel szívni, és csak egyszerű fájlelérés a cél, nem kell feltölteni meg ilyesmi. Az FTP egyszerű, fellövöm (pl. bftpd), a fogadó oldalon bármilyen OS alá szokott lenni kliens és elérem a fájlokat. Erre jó, de a nyilvános neten nem jó ötlet már 2018-ban FTP-vel szórakozni. Szép és jó volt az FTP, amíg nem volt torrent, meg ennyi https-ses, felhős, one click share oldal fájlmegosztásra.


No keyboard detected... Press F1 to run the SETUP

Pedig hasznos funkció volt, mert ha publikus ftp-re vitt egy link, akkor rögtön tudtam szemezgetni benne, hogy kell-e az ami benne van, vagy nem, szúrópróba szerűen letölthettem egy pár cuccot megnézésre.
A chrome böngészö engem amúgy sem érint, mert nem használom, csak tartok tőle, hogy előbb-utóbb a firefoxból is ki fogják hagyni.
Régen, amikor megjelent valamiből egy újabb verzió, biztosak lehettünk benne, hogy többet tudott mint az előző... kár, hogy a szoftverek fejlesztése abba az irányba tart, hogy az új verzióknál már attól kell félni, hogy vajon mit szüntetnek meg, vagy mit csesznek szét benne.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
/usr/lib/libasound.so --gágágágá --lilaliba

Mert ez sem biztonságos mint sok minden.
--
https://www.digitalocean.com/?refcode=7504fb2af065