ismét itt

Néhány év kihagyás után ismét a bloghu-n is! Lesz itt kérem hír, nanogrammban mért vélemény, okosságok, minden, mint a búcsúban! Tessék, csak tessék!

See also...

About

 

bardóczi ákos CV site

 

 

daily tweets from bardóczi Follow me @bardoczi

 

 

LinkedIN - ákos bardóczi LinkedIN

 

 

My stuff on the web

 

 

bardoczi.blog.hu bardóczi in da bloghu

 

 

bardóczi ákos postr áko.s @Post.r

 

 

blog.bardoczi.net bardóczi Tumblarity

 

 

science.bardoczi.net I'm, the bookworm

 

 

ákos*Blog*Spotting ákos*Blogspotting

 

 

bardóczi on Wordpress bardóczi on Wordpress

 

 

My Quora blog My Quora blog

 

 

LiveJournal brainstroms from me ákos Journal

 

 

Stay connected!

 

 

ákos on Google+ follow me on Google+

 

 

ákos VKontakte ákos VKontakte

 

 

ask me anything! Ask difficult questions on InnoCentive

 

 

My Quora blog Ask me anything on Quora

 

 

 

ResearchGate sciencific network Researchgate connect

 

 

More great stuffs

 

 

Are you ELEQT member? Feel free to connect me! ELEQT

 

 

BoaW my BestOfAllWorlds profile

 

 

bardóczi ákos on ASW my ASW profile

 

 

Expatriate Community for Expats worldwide InterNations.org

 

 

Old school contact:
akos@cerp.ch
PGP-fingerprint:
B29C CF16 B1AA 13FC 54E4 A912 D720 4E1C 899A 6E0C





Hirdetés

Törlés a Google indexből? Próbálkozni, na azt lehet.

2014.05.30. 15:45 | bardóczi ákos | 1 komment

Címkék: google cenzúra freedom of speech EU internet censorship circumvention törlés googleből

Google Search vs. EU. Röhög a vakbelem. Ahogy azt már korábban lehetett olvasni, az EU jogalkotói a jelek szerint totálisan megkattantak ezzel a törlősdivel, ugyan a hvg.hu és az index.hu ma címoldalon hoztatermészetesen kijátszható a dolog: a legprózaibb, hogy aki blogger karrierje során nevén nevezett néhány arcot, akik nem szerették volna, hogy nevükön nevezzék őket [én mondjuk nem szoktam], a posztot rövid időre leveszi a public view-ből, így az érintett alanyok nem tudják a Google felé továbbítani, hogy milyen URL-re is vonatkozna az eltávolítási kérelem. Amikor pedig ennek a törölgetési hullámnak vége, szépen visszateszi őket public view-ba.

A másik, hogy egyre hatékonyabb módszerek fognak megjelenni, amik arra irányulnak, hogy a tartalmakat mégse lehessen eltávolíttatni, ilyen pl. az URL-ekkel való trükközés [tankönyvi példa: dinamikus URL-ek], mirrorok, link-loopok, Google Webmaster Tools, meg még számos olyan dolog, amiről az EU törvényhozóinak szerencsére még senki sem mesélt. Ahogy alighanem nem mesélt nekik senki arról sem, hogy több éve működő teljes iparágat foglalkoztat - főként a tengerentúlon - az ún. reputation management, aminek az a lényege, hogy egy zaftosabb összeg befizetése mellett egy cég vállalja, hogy eltávolítja vagy háttérbe szorítja az ügyfélre nézve kínos információkat a neten. Nem mellékesen, ha valaki törlési kérelmet küld EU-állampolgárként, azt a Google Ireland kapja meg és bírálja el, ha még el is távolítják a kérdéses keresési találatot, az EU-n kívülről továbbra is kereshető marad, márpedig a Google-val úgy láttatni, mintha máshol lennénk, nem nagy bravúr.

A rendszer kijátszására irányuló módszerek pedig egyre kifinomultabbak lesznek, hiszen ebben az esetben sem kivétel a szabály alól, hogy mióta tömegkommunikáció létezik, minden kultúra, ahol valamilyen debil korlátozást vezettek be, ami a szabad információáramlást veszélyeztette, idővel magával vonzotta azt a hatást, hogy a tömeg megtanulta kijátszani azt

 

"De nekem nem láthatóak a Facebook-ismerőseim"

2014.05.28. 07:30 | bardóczi ákos | 5 komment

Címkék: adatvédelem webkettő facebook social media

Képzeljük el azt a prózaian egyszerű szituációt, hogy valamilyen okból tudnunk kell, hogy valakinek kik az ismerősei a Facebookon [2], viszont az érintett felhasználó letiltotta, hogy az ismerősei listája látható legyen. Persze, persze, egy kamu adathalász FB-kisalkalmazással ami az felhasználó “szives hozzájárulása” után lekérdezi mindezt, nem nagy bravúr. Viszont a Facebook alkalmazásfejlesztői környezetében [API] egyrészt nem tud mindenki (adathalász) szoftvert fejleszteni, másrészt ha a felhasználó explicite letiltotta, hogy kisalkalmazások a kontaktlistájához hozzáférjenek, mindez meghiúsul.

Ebben a posztban egy arcpirítóan egyszerű megoldást mutatok be, amin keresztül bárkinek a kontaktlistája lekérhető egyetlen programkód megírása nélkül.

Amikor egy szűz böngészőn keresztül – azaz nem pl. meghívóval – regisztrálunk a Facebookra, az illedelmesen felajánlja, hogy bővítsd az ismerőseid körét és onnan dob fel ajánlatokat ahonnan tud: a rendszer feltételezi, hogy a meglévő ismerőseid ismerőseit nagyobb valószínűséggel ismered, mint véletlenszerűen ajánlott felhasználókat, így eleve őket fogja ajánlgatni a jobb oldallécben. Könnyen belátható, hogy ha még nem nagyon léptél kapcsolatba senkivel és csak egyetlen ismerősöd van, az ő ismerőseit dobja fel – és, most jön a lényeg – teljesen függetlenül attól, hogy a meglévő ismerősöd a saját kontaktlistáját mások előtt rejtettre állította vagy sem. Azaz ha elegendő alkalommal frissíted az ajánlott ismerősök listáját, az összes ismerősdét kigyűjtheted, függetlenül attól, hogy azt elvileg láthatnád-e vagy sem, de a módszer még akkor is működik, ha a célfelhasználó az emlegetett kisalkalmazások számára az ismerősök leolvasását az API-n keresztül is tiltotta [1]. Ez mondjuk – számomra – abszolút nem új.

Amit viszont nemrég vettem észre, hogy, hogy a felvázolt esetben nem csak azokat a felhasználókat dobja fel ajánlottként, akik már a meglévő ismerőseid ismerősei, hanem azokat is, akiket ő ismerősnek jelölt vagy őt jelölték ismerősnek, de még nem igazolta vissza a kapcsolatot. Mindenki döntse el magában, hogy ez mennyire kínos, nekem csak egy leendő számítógépes nyelvész kérdése jutott eszembe: “ez most bug vagy feature?”.

Ismétcsak azt tudom mondani, hogy egy közösségi szolgáltatásban teljesen fölösleges a privacy settings-szel és a hasonlóan szépnevű audience selectorral játszani, hasonlóan ahhoz, ahogy a képek láthatósága is kijátszható volt látható minden más is vagy így vagy úgy, legfeljebb az lehet kérdés, hogy egy-egy módszer mennyire ismert.

Nem kalandoznék el nagyon, de összességében ismétcsak azt tudom mondani, hogy nem az a megoldás, ha bojkottáljuk a közösségi webes szolgáltatásokat, hanem az, hogy csak olyan tartalmat töltünk fel, ami szigurúan publikus.

[1] ennek az egésznek természetesen semmi köze az API-hoz
[2] oké, persze ez sokkal egyszerűbb a LinkedIN-en vagy az iWiW-en, amíg van, ui. nyilván ezek általában átfednek
[3] haladó kérdés: az ismertetett logika + egy FB-sajátosság alapján hogyan kérdezhető le a teljes ismerőslista ha több ismerősöd van, de csak egyvalaki ismerőslistájára vagy kíváncsi, aki mindenki előtt rejtve próbálja tartani az ismerőseit. Megoldás jöhet kommentben és emailen egyaránt!

Szervergyilkosság egyetlen Facebook bejegyzéssel

2014.05.02. 19:22 | bardóczi ákos | Szólj hozzá!

Címkék: facebook ddos ITsec

03-Facebook-Hack.jpgIsmert jelenség, amikor a Facebookon valakinek egy képet vagy videót tartalmazó tartalomra mutató linket küldünk, a Facebook elkészíti néhány másodperc alatt annak az előnézeti képét, amihez persze a linkelt helyről tölti le a képet, majd elhelyezi az egyik Facebook-szerver gyomrában, így ha legközelebb is megnézi valaki az általunk linkelt tartalmat, annak snippetjéhez már nem kell a forrás szerverről újratöltenie a képet a Facebooknak, ehelyett illedelmesen előveszi a saját példányát. Bizonyos esetekben viszont nem. Nemrég chr13 blogján jelent meg egy máig működő módszer, amiben azt demonstrálja, hogy a gyorsítótárazási technika hagy némi kivetnivalót maga után. Ugyanis ha egy Facebook note-ban egy külső helyre mutató képet hivatkozunk, csak egyszer történik letöltés, viszont abban az esetben, ha a képhez tartozik egy (dinamikus) GET paraméter is, a Facebook minden esetben megpróbálja újratölteni a teljes képet, azaz például ha a kép így lett beágyazva:

<img src=http://aldozatszerver.tld/file?r=1></img>

Fontos megjegyezni, hogy több kép is lehet egyetlen Facebook jegyzetben, ilyenkor mindegyiket megpróbálja a Facebook újratölteni. Nos, ha úgy számolunk, hogy egy Facebook jegyzetet nagyon sokan megnyithatnak, főleg, ha annak a linkje szét van szórva szerte Internetországban, a nagyságrendekkel megnövekedett letöltés még egy közepes méretű kép esetén is eszelős megterhelést ró a szerverre [GET flood], gyakorlatilag bekövetkezik egy elosztott túrterheléses támadás, ami után az áldozat webszerver nem tudja kiszolgálni a kéréseket, persze nem csak a hivatkozott fájlra vonatkozóan, hanem a teljes webszerver megfekszik. A chr13 blogjában leírt egyik tesztesetben 2-3 óra alatt több, mint 400 Mbps-mal nőtt a megcélzott szerver által felhasznált sávszélesség.

Ha nem akarunk pluszban DDoS -védelemre költeni, lényegében csak néhány, meglehetősen tahó módszerrel lehet próbálkozni az ilyen támadások kivédésére, mint amilyen a hotlinking tiltása, az összes látogató szögre akasztása még a bejáratnál, aki user-agentként facebookexternalhit -ként azonosítja önmagát a webszerver felé, esetleg egy Cloudflare webhely elé cibálása.