Facebook nüüd sibulavõrgus

tor-logoFacebook arendajad lisasid nüüd ennast Tor võrku:

https://facebookcorewwwi.onion/

Nüüd on kahekordne turvalisus: onioni enda 1024 bitine rsa ja facebooki ssl/https sertifikaadi krüpteering.
Kes tahab seda uut aadressi kasutada, peab paigaldama endale Tor nimelise tarkvara.

(toim: Paraneb ühenduse turvalisus ja pole täpselt teada, kus kohast te FB lehte vaatate.
FB teab ikka kellega te suhtlete, mis teile meeldib jne ning müüb seda infot kolmandale osapoolele, teenides teie edevuselt märkimisväärset pappi.
Facebook kasutamine võib teile maksma minna sooja töökoha. Kui ei usu, küsi Jürgen Ligi ja paljude teiste käest.
)

15 arvamust “Facebook nüüd sibulavõrgus” kohta

  1. No see on nüüd küll uudis, eriti kui arvestada, et enne-vanasti virutas Facebook läbi tor’i tulles ekstra “captcha” ette. Täpselt sama lugu oli LinkedIn’iga, kuid praeguse lause kirjutamise vahepeal testides näib, et isegi LinkedIn on selle poliitika ära muutnud ning LinkedIn-toimikud on Tor Browser‘iga täitsa ilma ekstra “captcha’ta” nähtavad.

    Üks esimesi mõtteid, mis minul Facebook’i kui igavese sigatseva äri-projektiga seoses mõttesse tuli, on see, et torvõrgu väljumis-lüüsid (“tor exit relay”) olid tõenäoliselt päris korralikult koormatud, mis tähendas tõenäoliselt seda, et samast väljums-lüüsist külastas lõustaraamatut rohkem kui üks inimene, mistõttu väljumislüüs võis toimida natukene segusti-sarnaselt, raskendades NSA-l ja CIA-l tor-võrgu analüüsi. Tor-võrgu statistikat vaadates näib, et Rootsi on kuidagi ebaproportsionaalselt suurelt esindatud ning kuskilt jäi mulle kunagi kõrva, et kunagi NSA olevat oma mega-klastri kõik legitiimseid tor-võrgu sõlmi täis pannud, eesmärgiga saada statistiliselt arvestatav kogus tor-võrgu liiklusest oma enda sise-võrku, lihtsustades sedasi tor-võrgu analüüsi ning alandades seeläbi tor-võrgu anonümiseerimis-võimet.

    Tor’i võrk on seotud hajutatud paisktabelitega (“distributed hash table”, “DHT”). Antud teemas on mul veel palju õppida, sõltumata sellest, et see teema mulle juba mõnda aega huvi on pakkunud, kuid nii palju tean, et sarnaselt klassikalistele sorteerimis-algoritmidele(“quicksort”, “bubblesort”, jne.) on ka DHT korral levinud vähemalt 2 “üldtuntud” algoritmi, Chord ja Kademlia, millel leidub erinevaid teeke. Mulle endale meeldib jälle üks natukene kolmandat moodi algoritm, millega ma järjekordselt enam-vähem dušiall välja tulin ning mis minu meelest sobib ehk DHT’de sissejuhatuseks kõige paremini. Järgnevalt üritan seda selgitada.

    —-selgituse—algus—–
    Teatavasti paisktabeli mõte seisneb selles, et hästi lihtsalt saab sinna salvestada andmete paare, millest ühte kasutatakse tema paarilise ülesleidmiseks.

    väärtus = ht_minu_paisktabel.get(võtmeväärtus)
    # Ruby stiilis kirjutatult:
    väärtus = ht_minu_paisktabel[võtmeväärtus]

    Näiteks:
    s_nimi=”Juku”
    i_juku_vanus = ht_vanused(s_nimi)
    s_nimi=”Mari”
    i_mari_vanus = ht_vanused(s_nimi)

    ht_vanused[“Juku vanaema”]=99 # vanuse salvestamine paisktabelisse

    Hajutatud paisktabeli funktsionaalsus on täpselt sama, kuid temas salvestatavad andmed on ära jaotatud paljude arvutite vahel, mis võivad asuda kõik korraga mõne ettevõtte IT-osakonnas, kuid mis enamasti on turvalisuse temaatikast inspireerituna ära jaotatud paljude arvuti-omanike vahel. Tööpõhimõtted, mille järgi andmed eri arvutite vahel ära jaotatakse, erinevad, kuid üks idee on järgmine:

    bitijada_andmete_võtmest = sha256(võti_näiteks_inimese_nimi) # sha256sum on Linuxi konsooliprogramm

    Bitijada abil saab kahendpuus kodeerida teed puu juurest suvalise tipuni. Näiteks “1” võib tähendada, et läheme hargnevuse korral “paremale” ning “0” võib tähendada, et läheme hargnevuse korral “vasakule”. Näiteks hakates sellel lingil asuva joonise korral puu juurest ehk tipust märgendiga “74” liikuma tippu märgendiga “76“, on teed kirjeldavaks bitijadaks 101. 74-jast 22-ni 000, jne.

    Järelikult sha256 algoritmi poolt kirjeldatav bitijada, sealhulgas eelnevalt mainitud

    bitijada_andmete_võtmest

    kirjeldab samuti teed mingisugusse puu tippu. Samamoodi kirjeldab teed puu juurest puu leheni

    bitijada_andmeid_salvestava_arvuti_IDst = sha256(arvuti_ID)

    Kui oleks võtta 2-astmes-bitijada_andmeid_salvestava_arvuti_IDst arvutit, mis oleks garanteeritult kõik alati töökorras, kättesaadavad, rahaliselt aksepteeritava maksumusega, jne. siis olekski hajutatud paisktabeli realisatsioon enam-vähem olemas, sest

    bitijada_andmeid_salvestava_arvuti_IDst == bitijada_andmete_võtmest

    Praktikas aga kõik arvutid ei tea, millise ID-ga arvuti millisel IP-aadressil asub ning sellise info salvestaminegi võtaks aksepteerimatult palju ruumi, rääkimata sellest, et kõik arvutid ei ole alati kättesaadavad ega töökorras ning ühes puu lehes asuv arvuti ei pruugi kõiki sinna puu lehte laekuvaid andmeid suuta ära salvestada ning osad puude lehed ei olegi andmeid salvestava arvutiga varustatud, jne. Antud juhtumil on praktikaga toime-tulemise lahenduse üheks lisa-meetmeks andmeid salvestavate arvutite paigaldamine lisaks puu lehtedele ka puu vahetippudesse (need, kus hargnemine toimub ehk eelnevaltki viidatud joonise korral tipud “42”, “1984”, “73”, jne.) ning igasse tippu panna rohkem kui üks arvuti, mis sama tipu teisi arvuteid dubleerib. Sedasi leidub iga ilma salvestusarvutita lehe korral teel juurest leheni vähemalt mõni tipp, kus on vähemalt üks salvestusarvuti.

    Ülejäänud mõtlete juba oma enda fantaasia abil välja ning seda loodetavasti kordades paremini, kui mina seda iial väja mõelda suudan. Kui Teile puu variant ei meeldi, siis võite näiteks proovida üldideed

    mingi_tore_koordinaat = Teie_kaval_funktsioon(andmete_võtmest_või_arvuti_IDst_genereeritud_bitijada)

    Näiteks 6 bitist koosnevat bitijada saab tõlgendada laevade pommitamise mängu stiilis 2D koordinaadina, kus 3 bitti on tulba selekteerimiseks ja ülejäänud 3 bitti rea selekteerimiseks. 6 bitti saab jagada ka 2-bitisteks kolmikuks, kus iga 2-bitine arv määrab ära ühe koordinaadi 3D ruumis. Variante jagub ning peamine küsimus on pigem selles, millist neist variantidest saab realiseerida nii, et igasugu kiiruse ja mälu ja kõvaketta-ruumi kasutuse küsimused soodsalt lahendatud oleks, turva-teemad ja muud töökindluse teemad talutavalt lahendatud oleks ning tarkvara-arendustöödele võimalikult vähe aega kuluks.

    —-selgituse—lõpp——

    Lugemise eest tänades,
    Martin.Vahi@softf1.com

    • Lisan hajutatud paisktabelite (DHT) jutule kommentaariks, et DHT algoritmi korral on oluline, et koordinaatidena tõlgendatavad räsifunktsiooni-väärtused oleks kuidagi modi järjestatud. Näiteks puu juurest puu lehe poole liikudes teele jäävad tipud, juur ja leht kaasa arvatud, on üksteise suhtes järjestatud. Analoog-kella tabloo arvud, 1,2,3,…10,11,12 omavad järjestust. Male-laua ruudud saab ära järjestada selle järgi, et alustada ruutude nummerdamist(1,2,3,4,…,64) kõige “ülemisest” reast ja siis iga rea korral liikuda vasakult paremale, jne.

  2. 2 Minu absoluutset lemmik-filmi 2014_11 seisuga on:

    Æon Flux,
    Ultraviolet.

    Rõhutan, et mu praegune kommentaar EI OLE teemaväline kommentaar. Kuigi, möönan, et olen korduvalt saanud kriitikat, et ma pidavat rääkima liiga keerukalt, kasutades liiga palju metafoore. Ise ma pean end üpris pikkade juhtmetega ja alla-keskmise IQ-ga inimeseks, kes peab teistega võrdse tulemuse saavutamiseks teistest rohkem tööd tegema, millest oletan, et viga ei ole minu jutu keerukas konstruktsioonis vaid selles, et minust oluliselt intelligentsemad inimesed ei suvatse mu juttu pea-aegu üldse süveneda.

    • Tänan põneva viite eest.

      Näiteks Bitmessage mulle 2014_11 seisuga ei meeldi, sest tollesse projekti on sõltuvusi kuhjatud ilma, et oleks mõeldud tolle projekti ehitatavuse töökindluse peale. Mina 2014_10 seisuga Bitmessage ehitamisega/kompileerimisega hakkama ei suutnud saada.

      Olles aastaid C++ koodi kirjutanud, mõtlesin 2014 suvel või septembris pikalt, et milles kiiruse järgi optimeeritud koodi, mis graafikakaardil ega FPGA-l ei jookse, kirjutada. Go praakisin välja, sest see ei toeta erindeid(“exceptions”). Aeg piisavalt edasi läinud, et vaid programmeerimiskeele hindamisest ei piisa ning tuleb hinnata ka programmeerimiskeelega kasutatavaid formaase verifitseerimise tööriistu ning tarkvaratoimeteid. Java on välistatud sõltumata OpenJML‘i olemasolust. C keele jaoks on loodud Frama-C ning mitmed muud (BitC, SATABS, jne.) töövahendid ning Wolverine pidavat isegi C++’i toetama, kuid C/C++ on moraalselt vananenud kasvõi ainuüksi põhjusel, et päisefailis tuleb dubleerida infot, mis c/cpp failis juba kirjas on. See, et operaatorite kujul olevaid funktsiooniväljakutseid vältides on võimalik ise C++ standard-teegist kiiremaid versioone kirjutada, pole C++ korral ehk isegi nii suureks probleemiks, kuid aeg on midagi fundamentaalselt läbimõeldumat kasutada, millest siis minu otsus, et süsteem-programmeerimis-keeltest kavatsen järgmiseks ära õppida Ada, kõik uued seda-sorti projektid Ada-s teha. Omaette seik on ka asjaolu, et erinevalt C++’ist on lõimede(“thread”) tugi Ada’sse kohe algusest saadik sisse konstrueeritud. 2014_11 seisuga vajab kogu Ada temaatika minu korral veel kõvasti õppimist, kuid korjasin internetiavarustest omale (ja teistele, kui keegi peaks tahtma) kokku esmase Ada-ga töötamise töövahendite komplekti. 2014_11 seisuga ma veel ei tea, kas selle komplekti komponendid on üldse kasutuskõlblikud, sest ma pole jõudnud veel proovida.

      Tagasi teemasse tulles, viidatud Tox näib olevat kirjutatud C++’is, mistõttu isegi olukorras, kus mul selle projekti jaoks oma muude hädade (Sireli vead, Raudrohu vead, jne.) kõrvalt tegelemiseks aega oleks, on mul kiusatus uurida, mida nad protokolliks koostavad ning nende abistamise asemel kirjutada nende võrgustiku protokolli toetav Ada teek, eeldusel, et nad protokolliga puusse ei pane, näiteks GNUnet‘i kombel turva küsimustes latti minu subjektiivse maitse kohaselt liiga alla ei lase.

      • Mu praegune kommentaar käsitleb Ada-t.

        Kunagi, ammu-ammu, arvasin ma Ada-st ja Java’st nõnda. Java’ga on lood ühel pool, kuid mu praeguse kommentaari krooni-juveel seisneb järgnevalt tsiteeritud kommentaaris, mis _ei ole_ minu kirjutatud:

        DwayneU Posted: Feb 2, 2009 11:45 AM EST

        Having talked with other dinosaurs that were around in the 80s era when Ada was initially mandated, I think that two factors were primary contributors to the limited acceptance of Ada.

        First of all, the DoD mandate. This had two effects. First the US defense industry bristled at being told that they had no option other than to use Ada. Western thinking sometimes elevates the freedom of choice above an acceptable constraint. The second effect of the mandate was that immature compiler had to be used to make program schedules. Quickly release immature complier suites provided buggy development environments and less than efficient code generators. The initial impressions of a new strongly typed language, mandated use, buggy compilers and poor code generation are hard to overcome.

        The second factor was the pricing approach of the compiler companies, which was also influenced by the DoD mandate. Ada compilers were obviously more expensive to develop. Many (mabe all?) compiler companies decided to increase the cost of licenses to pay off the development costs in a very short period of time (ie. a small number of seats). With the DoD mandate in place, this seemed like a viable financial approach to recoup their investment quickly just in case this Ada-thingy didn’t catch on.

        With two decades or so of Ada history behind us, there are still language battles, but for the most part, I see the Ada market share decreasing.

        2014_11 seisuga arvan, et Ada-l on tulevikku küll. Olen praktikast avastanud, et mõned projektid, mis on hästi hoolega tehtud ning millel on tipp-tasemel arendajad, võivadki olla sõna otseses mõttes aastakümneid vähe-populaarsed, kasutuses ning enam-vähem hooldatud. Näiteks REDUCE on üle 40 aasta vana, omades aktiivset profi-matemaatikutest kasutajaskonda ning vähemalt ühte originaal-autorist arendajat, kelleks on pensionile läinud akadeemikust Arthur Norman. Teine elujõulise ning õnnestunud dinosauruse näide on Vim. Näited on mul loomulikult rohkem, kuid vormimahu huvides ma ei hakka neid kõiki siin loetlema, vaid sõnan, et kõigi vastavate näidete üheks ühiseks omaduseks näib olevat asjaolu, et tarkvara on kohe algusest saadik hoolikalt läbi mõeldud, ei ole kiiruga üks-kõik millest kokku klopsitud, on kirjutatud arvestusega, et kogu projekt peab olema kompileeritav programmeerimiskeelte standardteekidest ning projekti koodipublikatsioonis sisalduvast materjalist. Näiteks REDUCE on kirjutatud Lisp’is, kuid Lisp’i interpretaator on REDUCE projekti osaks ning kirjutatud enam-vähem igale poole porditud C’s.

        Arvan, et tuleb leppida asjaoluga, et tehniliselt tõsiselt head asjad kipuvad omama siiski vähemalt mingisugust keerukkust ning keerukad asjad ei saagi kunagi üli-populaarsed olla, sest nende kasutamine eeldab õppimist. Teatavasti inimestele ei meeldi õppida, sõltumata õppimisest saadavast ajavõidust. Lihtrahvalikuks illustratsiooniks sobib kümnesõrmesüsteemi oskus ehk oskus klaviatuuril kirjutada ilma, et klaviatuuri vaataks. Aastal 1999 kümnesõrmesüsteemi kursusi korraldanud ning praeguseks kahjuks manalateele läinud Pr. Viivi Dikson TÕESTAS PUUST ETTE ja ilma vereta, et antud oskus on enamikel inimestele sõna otseses mõttes 2 nädalaga, 2h päevas harjutades, omandatav. Samas, kui palju aega kulutavad mitmed dokumentide kirjutamisega hommikust õhtuni tegelevad ning päevas mitmeid e-kirju kirjutavad müügimehed ja muud ametnikud klaviatuuri vahtides toksimisele?

        2014_11 seisuga oletan, et kõik programmeerimiskeeled ei peagi päris kõike, näiteks 3D-d ja piltide ekraanil kuvamist, võimaldama. Mulle näib, et niiöelda “universaal-programmeerimiskeeltel” siiski eksisteerib teatud komplekt funktsionaalsust, ilma milleta universaal-programmeerimiskeel ei ole praktikas kasutatav. Lihtsaimaks näiteks võiks ehk sobida võimalus faile lugeda ning kirjutada. 2014. aasta olustiku järgi komplekteeritud detailide loetelu kohta on mul koostatud joonis, kuid selle muudetav, elus, versioon asub praeuse kommentaari lugemise hetkeks tõenäoliselt puruks oleval lingil. Teisest küljest, kui mõelda, et tava-keel on vahend inimese maailmanägemuse kirjeldamiseks ning programmeerimiskeel on vahend programmeerija maailmanägemuse modelleerimiseks, siis puht kultuuriliselt võiks päris huvitav olla teada, milliseid programmeerimiskeeli kasutatakse aastal 2600. Üheks võimaluseks on see, et 1984 tingimustes läheb tarkvara-arendus-tehnoloogiaga sama moodi nagu läks Alexandria raamatukoguga.

        Tänan lugemast. :-)

  3. Ma alamprogrammeerimisega ammu juba ei tegele. Mul on programmid, mis kontrollivad teisi programme ja loen ainult logisi ja annan vajaduse korral terminalis paar käsku.
    Kuna distributsioonid ja programmid uuenevad märgatavalt, siis bashi ja debiani ümberkorraldustest olen loobunud.
    On korni kloon ja üks tuum, mille augud peksavad kinni ufw/iptables tulemüüri seaded.
    AInult mõnikord naljapärast loen koode ja .configure make install (kui veel teegid lubavad)–

    Üldiselt soovitan minu tehnikat võtta kasutusele: kaks OSi ühe arvuti jaoks(eri ketastel): üks testimiseks ja binaarimiseks- teine, mida kasutad ja kuhu binaarid ja teegid tood- see nõuab põhjalikku teadmist teekidest ja ühilduvusest.

  4. Minu arvutis puudub non-free tarkvara ja kinniseid koode ei ole. Võib ju kuulata-vaadata vaba litsentsiga filme, helifaile. Tarkvara on siis vaba kui selle lähtekoodid on loetavad ja vabade õigustega.

    Avatud lähtekood (open source) ei ole veel vaba tarkvara kui litsents on piiratud või sisaldab non-free koode.

    Ka tor on 2otsaga asi.

  5. Üks link artiklile, kus kirjeldatakse, kuidas Hiina Tulemüür GitHub‘i ära tsenseeris (blokeeris). Minu mõte on, et arvestades USA tsensuuri kulturi, kus raha eest renditud virtuaalmasinas tor’i tööle-laskmisel virtuaalmasinarendi-teenuse pakkuja administraatorid tor’i tuimalt välja lülitavad ja ähvarduskirja saadavad, GitHub’i konto, kus enamus failidest on pornofilmid, tõenäoliselt kustutatakse.

    Ma küll pornofilmidega ei tegele (iial ei tasu öelda, ei iial, eks ju :-D, kuid mu enda vastumeede on, et ma kasutan GitHub’i peamiselt vaid reklaami-kanalina, võimaldamaks koodi hõlbsamalt kuvada ning peamise publitseerimis-keskkonnana kasutan omaenda kodulehekülge, kus defektide infosüsteemiks (“bugtrack”) on kasutusel Fossil. Siis on kindel, et ainukene oht on PirateBay ja WikiLeaks’i stiilis serverite ning domeenide maha-võtmine ning mul on võimalus kogu oma kodulehest rekursiivselt varukoopiaid teha. Koos arhiivi ning muuga on seda 2014_12 seisuga suurusjärgus 20GiB, aga kord kuus 20GiB alla laadida ja oma arvutis olevasse Git’i koodihoidlasse salvestada on täitsa talutav.

    Rääkides reklaamikanalitest, siis lisaks npmjs.com‘ile ning GitHub’ile leidub ka selline asi nagu openhub.net, mis on 2014_12 seisuga küll tiguaeglane (15s ühe lingi teenindamisele) ning muidu natuke viletsa kujundusega, kuid näib olevat üks kohtadest, kust õnnestunumal või ebaõnnestunumal viisil inimesed tarnijaid otsida võiks.

    Tänan lugemast. :-)

    • Irooniana mainin, et paljude armastatud ja üle maa ja ilma kuulsust kogunud RedHat on atraktiivse kompna välja tulnud 2014_12 pakkumisel oleva OpenShift-nimelise teenusega, kus, sõltumata sellest, et vaid ühe tähe ära-jätmisel saab selle nimest fraasi “open-shit”, pakutakse degusteerimise vormis virtuaalmasinaid, mis, vähemalt lubaduse järgi, lülituvad sisse-tuleva liikluse puudumisel end 24h jooksul välja ja sisse-tuleva liikluse taastumisel buudivad end uuesti üles. Degusteerimisel pakutaval virtuaalmasinal on 1GiB HDD ning 512MiB RAM. 2014_12 seisuga pole ma seda veel katsetanud, kuid kui tor’i mitte jooksutada ja kogu andmesideühendus filtrite lollitamiseks ning JOKK’itamiseks vahemeherünnet võmaldava avatud võtme krüptoga, näiteks GNU-pg, ära krüptida, siis võiks olla tegu päris kena lahendusega, mis peaks võimaldama planet.ee teenusega kombineeritult 12€ aastatasuga luua päris ilusaid arvutusvõimekusega infosüsteeme.

Kommenteerimine on suletud