bardóczi ákos @post.r

Ahogy arról hétfőn beszámoltam, idén az orvosi-fiziológiai Nobel-díjat az autofágia genetikai szabályozásának feltárásáért ítélték oda.

Az élő sejtekben, ugyan sejttípustól eltérő mértékben, de folyamatosan sérülnek, kiöregszenek, így egyszerűen javításra vagy ha az már nem megy, lebontásra szorulnak bizonyos kisebb struktúrák, az ún. organellumok avagy sejtszervecskék és az azokat alkotó makromolekulák. Abban az esetben, ha ez nem lenne garantált és óramű pontossággal szabályozott, felhalmozódna számos működésképtelenné vált organellum vagy éppen hibásan tekeredett fehérje, ez pedig nagyon gyorsan a sejt halálához vezetne.

A belső törmelékek lebontását külön, erre specializálódott organellumok végzik, amiket lizoszómáknak nevez a szakirodalom. A lizoszómák a fölöslegessé vált makromolekulákat egyre kisebb részeire, akár monomerjeire is bonthatják, közvetve segítik más organellumok újraépítését, esetleg egyszerűen eltüntetik, amit megemésztettek, de olyan is előfordulhat, hogy a sejt belsejének többi részétől elkülönített, memránnal határolt csomagban zárványként maradnak jelen. Olyan is előfordulhat, amikor a lizoszómába egy teljes organellum kerül bele, ezeket a struktúrákat nevezi a szakirodalom autofagoszómának.

Ahogy korábban is utaltam rá, sebészi pontossággal szükséges felismernie a sejtnek, hogy mik azok a részek, amiket le kell bontani, mik azok, amiket nem, majd ugyanilyen pontossággal levezényelni a teljes folyamatot, minderre pedig természetesen számos forgatókönyvet készített az evolúció.

A japán kutató penészgombákon keresztül azt tanulmányozta, hogy bizonyos gének kiütésével hogyan módosul az autofágia folyamata, ilyen módon szisztematikusan sikerült feltérképezni a szabályozásban szerepet játszó gének hálózatát. A gombák esetében talált gének analógjai vagy maguk a gének pedig megtalálhatók a növényvilág képviselői és az állatvilág legkülönbözőbb tagjai közt is, így az emberben szintén. Mindennek az orvosi jelentősség abban áll, hogy ismeretesek olyan betegségek, amikkel együtt jár az autofágia hibás működése, így a jövőben a közvetlen molekuláris medicina számára is fontos targetté válhat a félresiklott folyamatok helyreállítása.

Vannak esetek, amikor veleszületett rendellenességként a lizoszómák nem tudják lebontani vagy tárolni a szükséges anyagokat, amik még abban az esetben is súlyos tüneteket okozhatnak, ha egyébként csak bizonyos sejttípusok esetén jelentkeznek.

A Gaucher-kór esetén például csak a fehérvérsejtek egy bizonyos típusa, a makrofágok érintettek, amik nem tudnak lebontani egy bizonyos típusú makromolekulát. A kór egyik típusa nem okoz különösebben súlyos tüneteket és enzimterápiával kezelhető is, míg a másik két megjelenési formája rendszerint korai halált eredményez.

A Hunter-szindróma ugyancsak egyetlen enzim defektusára vezethető vissza, ami miatt a lizoszóma képtelen tárolni egy létfontosságú enzimet, ami miatt a dermatán szulfát és a heparán szulfát, létfontosságú struktúrfehérjék forgalma gátolt.

A szintén lizoszomális enzim hiánya okozta Fabry-kór esetén ugyancsak a teljes testet és persze életminőséget befolyásoló tünetek jelentkeznek, ebben az esetben emlékeim szerint az egyik galaktozidáz enzim teljes vagy részleges hiánya okozza a súlyos megbetegedést.

Eméleim szerint még legalább 20-30 betegség ismert, amikor a lizoszóma és ezzel együtt az autofágia valamilyen defektusa felelős súlyos tünetekért, az esetek többségében a lebontásra szánt makromoelkulák bejutnak ugyan a lizoszómába, a lebontó enzim hiánya miatt elbomlani már nem tudnak.

Kép: nobelprize.org

Ahogy az Origón is volt róla szó, akinek volt ingyenes Microsoft Onedrive tárhelye, de nem jelezte, hogy az eredeti méretű tárhelyet szeretné használni továbbra is, annak a 15 illetve 30 GB-os méretű tárhelyét csökkentették 5 GB-osra, ami eléggé drasztikus lépés, emellett az Office 365 felhasználók korábban korlátlanként kínált tárhelyét 1 terabájtosra korlátozták.

Mi történt előzőleg? Hónapokkal ezelőtt lett belőle egy kisebb cirkusz, hogy a Microsoft korlátozza azoknak az Office 365 felhasználóknak a tárhelyét, akik figyelmen kívül hagyták a fail usage policy-t, azaz azt az írásban foglalt szabályt, ami szerint jelen esetben a felhőszolgáltató korlátlan tárhelyet ad, de a felhasználóról jóhiszeműen úgy gondolja, hogy nem generál ésszerűtlen adatforgalmat és nem tárol ésszerűtlen mennyiségű adatot a tárhelyén.

Itt megjegyzem, nagyon nem világos, hogy miért nem tudta a Microsoft a fair usage policyra hivatkozva csak az érintett felhasználók fiókjainál érvényesíteni a korlátozást. Azon sem lennék meglepve, ha döntően azok a felhasználók ontották volna fel a tárhelyre a HD poreszt terabájtos dózisban, hogy ne az ő gépükön tárolja a helyet, na meg a bővítményes mentéseket a saját gépük teljes tartalmáról, akik még csak nem is saját maguknak fizették az Office 365-öt, hanem például a munkahelyükön vagy az iskolájukon keresztül kapták. Megjegyzem, a Microsoft Magyarország egy nem is olyan régi kezdeményezés keretében a közoktatásban felsőoktatásban tanulók számára ingyenesen elérhetővé tette az Office 365 iskolai kiadását, hogy majd a munka világába kilépve a diákság tagjai mégse Google Docs-szal, Google Drive-val, Facebook-csoportokkal meg hasonló trágyákkal égessék már magukat vállalati környezetben. Persze a Microsoft azért mindezt annak tudatában lépte meg, hogy úgyis csak néhányan fognak majd átszokni a Microsoft-felhőre, hiszen könnyen belátható, hogy a kedvezményt kapott tanulóknak csak a töredéket használná ki az egy terabájtos tárhelyet, már az is bőven meghaladná az európai MS cloud kapacitásait amellett, hogy pokolian ráfizetéses lenne. Azaz a szolgáltató mindig úgy matekozik, hogy lesz ugyan néhány heavy user, viszont nagyon sokan csak minimális mértékben vagy se használják a szolgáltatást.

Ugyan a blogon volt már ugyanez, de annyira zseniális a sztori a csávóról aki az átalánydíjas svédasztalos étteremből ki lett tiltva, mert túl sokat zabált, hogy ismét beteszem, mert végülis nagyon hasonlóról van szó.

"Évek óta kering az interneten egy legendás bejegyzés, amelyben egy elégedetlen vevő leírta, hogy őt eltanácsolták egy budapesti svédasztalos étteremből, mert túl sokat zabált.

Sokan nem hittek abban, hogy meg lehet enni ezt a menüt: Egy eperkrémlevest, majd egy frankfurtilevest. Ezt követte egy meleg előétel: kacsamellfalat. Majd ettem KETTŐ szelet húst rizibizivel, fokhagymás mártással. Továbbá ettem kb. tíz "kisháromszögnyi" füstölt karaván sajtot, tökmagot, és egy tányér sült krumplit (álánatúr). Ezt követte kb. három dinnyefalat (kb. két harapásnyira voltak felvágva). Megettem egy banánt (kettőt vittem el, de egyet elcsórtak az asztaltársaim), valamint apránként egy pár kanál pirított tökmagot. Végezetül desszertként megettem két madártejet (kb. két deci volt egy), egy sárgadinnyés-túróhabos fagyit (egy gombóc fagyi, egy gombóc sárgadinnyés túróhab), meg még további két gombóc vaníliafagyit. Megittam 2 x 2 dl őszilét, egy fél pohár sangriát, két pohár kólát valamint egy kapuccsínót."

A következő fájlhoszting szolgáltatók biztosítják a megszokott szolgáltatásokat, azaz webes felületen elérhetőek, több platformra lehet telepíteni hozzájuk kilensprogramot, akárcsak a Onedrive, Google Drive vagy MEGA esetén. Ami fontos különbség, hogy míg bizonyos szolgáltatók esetén csak maga a regisztráció idegen nyelvű, aminél viszont minden további nélkül bekapcsolható a Chrome fordítója, ha valakinek az orosz problémát jelentene, a regisztrációt követően már a webes felületen az egészet át lehet állítani angol nyelvűre és rendelkezik angol nyelvű klienssel is, míg a kínaiaknál vagy nem vagy nem találtam meg.

Mail.ru Cloud – az „orosz freemail” felhőszolgáltatása lealázva mondjuk a Google Drive-ot,  kapásból 25 GB tárhelyet ad közvetlenül a regisztráció után, ha a felhasználó telepíti a mobilkliensét is, de nem kötelező azon keresztül semmit sem feltöltenie.

Az európai szemmel jóval barátságosabb Yandex Disk, amiről korábban már írtam itt, 10 GB-tal indít, néhány kattintással állítható át angol nyelvűre, ha pedig telepítjük a Yandex Mail mobilappot, kapásból 26 GB-os gyors és biztonságos tárhelyet kapunk minden földi jóval. Gyakorlatilag tökéletes alternatívája a Google Drive-nak, de inkább még jobb is.

Mivel nem próbáltam ki, inkább csak a leginkább vállalkozó szellemű felhasználóknak geekeknek merném javasolni a kínai telco gigacég, a Tencent által nyújtott szolgáltatáscsoport fájlhoszting szolgáltatását, ami 10 TB (!!) tárhelyet garantál egy kis trükkel.

Ha minden igaz, a jól ismert QQ instant üzenetküldő szolgáltatásra kell regisztrálni, ami még angol nyelvű. Ezt követően a mobilra letöltött Tencent Cloud-ba a QQ-azonosítóval belépve már meg is adja a Tencent a 10 TB-os tárhelyet, amit aztán a Weiyun oldalán lehet ellenőrizni. Így egy kicsit zavaros lehet, de teljesen arról van szó, mint a Microsoft Account vagy a Google Account esetén: a regisztrációkor létrejövő fiókkal nem csak a levelező vagy instant üzenetküldő szolgáltatás érhető el, hanem több száz másik, így a Google esetében a Gmail, Google Analytics, Youtube, Google Drive, Google Keep, Google Calendar, Google Hangouts és így tovább. A Tencentnél teljesen hasonló a helyzet, csak éppenséggel a szolgáltatáscsoport tagjainak ilyen-olyan, egymásra még csak nem is hasonlító nevei vannak.

A Tencentnek valószínűleg full mindegy, hogy mekkora tárhelyet kínál, mivel Kínában alapvetően a net is lassabb, másrészt mindig tartsuk észben, hogy a szolgáltató korlátozhat az egyben fel- és letölthető fájlok méretét, a fájlok számát illetően, de korlátozhatja a tárolható fájltípusokat és a feltöltési sebességet is. Ha valaki úgy gondolná, hogy ezek az átlagos felhasználót úgysem érinthetik jobban ismert szolgáltatások esetén, annak ajánlom mondjuk ezt na meg ezt a másik összehasonlítást.

10 terabájtos tárhelyet írtam előbb? Hát persze, hogy lehet überelni! A Qihoo nem kevesebb, mint 36 TB-t ad, ha igaz, amit itt le van írva, ugyan lehet, hogy egyik-másik bravúr némi kínai nyelvtudást igényel, ugyan abban nem lennék teljesen meggyőződve, hogy az összes feltelepítendő app csak azt csinálja, amit valóban csinálnia kell és nincs valamelyikben ordas nagy backdoor, tehát ezeknek a kipróbálása az előzőhöz hasonlóan, virtuális gépen ajánlott.

De miért éri meg cégeknek dög nagy tárhelyet adni ingyen? Nos, sokszor végképp nem egyértelmű, de a Google esetén az IT kapacitáshoz képest a 15 GB-s tárhely lényegében erősíti a brandet. Másrészt sokszor az üzleti modell végképp nem világos, viszont ha arról van szó, hogy ennek a hátterében milyen infrastrukturális megvalósítás áll, semmiképp sem hagyományos szervereket képzeljünk el, hanem olyan fémtömeget, amit esetleg a gyártó kimondottan az adott web giant igényeinek megfelelően gyártott le, ha pedig nagy tömegben gyártanak le valamit, egy bizonyos szintig az ára annál inkább csökkenthető. Viszont ne feltételezzük egy-egy dög nagy tárhelyről, hogy ott aztán az adatok az örökkévalóságig léteznek, a Google és a Microsoft is fenntartja a jogot, hogy valamennyi inaktivitás után egyszerűen törölje a felhasználó minden adatát, másrészt ha valami gyanusan olcsó, annak a rendelkezésre állása sem teszi lehetővé, hogy egy szervezet nagyon támaszkodjon rá. Alighanem még a Google Apps adminisztrátorok közül is sokan nem tudják, de könnyedén beállítható, hogy ha valamilyen meghibásodás van abban az adatközpontban, ahol az adott szervezet adatait tárolja a Google, akkor arról küldjön emailen értesítést. Bekapcsoltam, gyakorlatilag nincs nap, hogy valamelyik, ráadásul fontosabb szolgáltatás részleteges ne halna le. Mivel a mezei Google szolgáltatások ugyanazon az infrastruktúrán futnak, mint a fizetős Google Apps különböző változatai, ezért feltehetően a Googlenél is teljesen hasonló a helyzet, csak nem annyira világos.

Ha arra vagyunk kíváncsiak, hogy valójában mennyi lehet üzemeltetni egy tényleg stabil fájlhoszting szolgáltatást, akkor például a Rackspace sávszélesség- és adattárolás árazásából lehet rá következtetni, abból pedig gyorsan kiderül, hogy nem olcsó mulatság.

Röviden: ismétcsak az első kérdés, hogy mi, miért, milyen rendelkezésre állással szeretnénk tárolni, különben értelmetlen feltenni magát a kérdést, hogy melyik fájlhoszting szolgáltató a legjobb. Ha valaki nem szeretné, hogy a letorrentezett HD pornó kollekciója, ami mennyiségében annyi, hogy alighanem az életbe nem tudná mind megnézni, ne a gépen tárolja a helyet, nyilván feltölthető olyan helyre, ahol nem olyan kínos, ha adatvesztés történik. Ha viszont dokumentumokat kell tárolni, de úgy, hogy abból garantáltan egy gramm se vesszen el, nyilván teljesen más a helyzet.

A jelszavakkal kapcsolatos közhelyeket annyival egészíteném ki, hogy ha meg akarjuk védeni azt, akkor nem feltétlenül a legbölcsebb dolog feltolni a netre… Nem, titkosítva sem. Igaz, hogy a mai jelszókezelő szolgáltatások olyan titkosítást használnak, amik elvben lehetetlenné teszik a jelszavak kinyerését a mesterjelszó ismerete nélkül, egy pillanatig se felejtsük el, hogy hány és hány, matematikailag cutting-edge titkosítást használó szoftverben találnak hibát rendszeresen! Azaz amikor valami konkrétan észrevétlenül maradt programozási hiba miatt törhető.

Én sosem használtam netes jelszóemlékeztető szolgáltatásokat, viszont ha betartom a jelszó erősségével kapcsolatos irányelveket és természetesen nem használom ugyanazt a jelszót még csak két azonos helyen sem, két lehetőség marad: az egyik, hogy kitalálok valami rendszert arra, hogy hogyan képezzem a jelszavaim, ami függ a szolgáltatás nevétől vagy típusától például, a másik pedig az, hogy a jelszavakat valahova felirkálom.

A következőben egy mindenki számára kivitelezhető módszert mutatok be arra, hogy hova érdemes a jelszavakat felirkálni, ha már a mai világban egyszerűen nincs más ésszerű megoldás, hiszen ha használsz olyan 20 jelszót, amit meg is változtatgatsz havonta és azok kellően bonyolultak is, kizárt, hogy mindet fejben tudd tartani.

Mit NE tegyünk? Ha már elvetettük a netes jelszókezelő alkalmazásokat, kézenfekvőnek tűnik létrehozni valamilyen Office dokumentumot, Excelt vagy Word-öt, amibe aztán szépen bemásoljuk az összes jelszót és azért, hogy egyetlen megnyitással vagy a fájl ellopásával mégse kerüljenek ezek a hozzáférési adatok olyanhoz, akihez nagyon nem kellene, az Office fájlt titkosítva mentjük. Mi ezzel a baj? Ismétcsak tisztában kell lenni vele, hogy a dokumentumok jelszóval való védelme rendeltetése szerint mire alkalmas és mire nem. Az Office dokumentumokat ugyan többféle titkosítással is menthetjük, alapvetően ezek gyenge titkosítások. Másrészt ha megnyitsz például a egyszerű DOC fájlt, akkor megjelenik tipikusan a vele azonos lévő mappában egy rejtett fájl, ami gyakorlatilag annak a fájlnak a nyers példánya, amin aktuálisan dolgozol és törlődik, ha a dokumentumot bezártad. Ha viszont valaki másnak is hozzáférése van a munkamappához például hálózati meghajtón keresztül vagy éppen csak lefagy a gép, igen, kitaláltad: a Word vagy Excel által átmenetileg létrehozott fájlt szépen ott marad, titkosítatlanul vagy épphogy titkosítva, aztán később viheti, aki látja.

Mennyivel elegánsabb, ha egy jelszót olyan helyen tárolunk, ahol ember nem gondolná, hogy ott tároljuk, másrészt mégis bizonyos esetekben kellő biztonságot ad: a szteganográfia.

A weben kismillió megoldás akár online is kínálja, hogy az általad beírt szöveget, mondjuk jelszavakat belevési egy MP3-ba, képfájlba, akármibe, ami aztán később letölthető, megnyitva pontosan olyan, mintha MP3 illetve képfájl lenne, viszont a megfelelő szerkesztővel megnyitva kinyerhető a bele rejtett szöveg. Ilyen webes szolgáltatásokat nem mernék ajánlani senkinek, hiszen nem lehetünk benne biztosak, hogy a szolgáltatás nem épphogy a jelszavak lenyúlására van kitalálva.

A legegyszerűbb megoldások egyikét viszont megmutatom, amit nevezhetnénk akár kézműves kriptónak is. Az alapján az jelenti, hogy a különböző fájltípusok, jól ismert és alaposan dokumentált szerkezettel rendelkeznek. Ha például érdekel, hogy egy egyszerű JPEG kép, ami semmilyen metaadatot nem tartalmaz, tényleg csak annyit, hogy tömörített vagy sem, milyen színmélységet használ, milyen a szélessége és hosszúsága, nos, itt körülbelül egy atomrakéta tervrajzának pontosságával van leírva, holott tudjuk, hogy a JPEG számtalan metaadatot tartalmazhat és tartalmaz is, mint például azt, hogy milyen fényképezőgéppel készült a fotó, a Photoshop melyik verziójával igazítottak rajta és így tovább.

Ami a mi szempontunkból lényeges egyszerűsítve, hogy a mostani JPEG egy olyan tömörített képfájl típus, ami többek közt ellenőrzőösszeget is tartalmaz, azt is, hogy a kép meddig tekinthető még egyáltalán az eredeti képnek. Bizonyos esetekben ha csak minimálisan sérül a fájl olyan módon, hogy néhány bájt megváltozik benne, a képet vagy meg lehet nyitni vagy nem, megint más esetben, vegyük azt az egyszerű példát, amikor a JPEG tömörítettsége 0, akár jelentős „zaj” is lehet a fájlon belül, amit egyszerűen nem fog értelmezni a képnézegető program vagy a sérüléseket figyelmen kívül hagyja, de természetesen utazik a fájllal együtt, ha például azt lemásoljuk. És itt a lényeg: hogy ez a bűvös zaj bizonyos terjedelmi korláton belül szinte bármi lehet.

Első lépésben tehát szükség van egy tetszőleges formátumú képfájlra. Ezt követően egy tetszőleges képszerkesztővel nyissuk meg és mentsük el JPEG-be olyan módon, hogy egyáltalán ne alkalmazzon a képszerkesztő tömörítést.

Ezt követően az új, teljesen tömörítetlen fájlt nyissuk meg egy olyan szövegszerkesztővel, ami plain text szerkesztésére alkalmas, azaz mondjuk notepaddel vagy ahogy tetszik, valami ilyen rémség fog látszódni.

Ezt követően egy ritkább helyre [nem magyarázom] helyezzünk egy tetszőleges szöveget, mondjuk egy részletet Shakira-tól.

A nyers szövegként szerkesztett fájlt mentsük az eredeti formátumban, majd ellenőrizzük, hogy megnyitható-e. Megnyitható!

Ezt követően, ha előkukáznánk azt a szövegrészt, amit a képbe rejtettünk, csak egy egyszerű szöveges böngésző kell.

Persze, erre lehet mondani, hogy a JPEG különböző metaadat mezőjébe is bőven el lehetne rejteni ezeket, a JPEG metaadatait a Windows és az OSX nagyon gyorsan indexeli és aszerint is kereshetünk ugye. Viszont abban az esetben, ha adott egy mappa mondjuk ezer metallica-s képpel, még egy erősebb géppel is piszok sok időbe telik, hogy valaki, aki ki akarja nyerni az így elrejtett szöveget, megtalálja azt, hiszen alapvetően fájlformátumtól függetlenül egy adott szövegrészre keresni fájlok belsejében egy komolyabb fájlkezelővel vagy scripttel még mindig veszettül lassú.

Természetesen ajánlható ezen kívül, hogy a mappát, aminek a képei közé rejtettük a belevarrt szövegrészt, titkosítsuk linuxnál Truecrypttel, Windows esetén EFS-sel, OSX esetén pedig Filevaulttal, a legnormálisabb megoldás pedig persze az, ha pendrive-on van, az, hogy ez mezei pendrive, EFS-re formázott vagy hardveres titkosítást alkalmazó, már csak attól függ, hogy az igen csak hasznos paranoiditás milyen szintjén vagyunk.