HUP Privacy Project

Kis trollkodás is a jó irányba terelhet!
:P

No rainbow, no sugar

"Szerver oldal nélkül akarom megoldani."

Hmm, akkor hol fogod tarolni a mar titkositott fileokat?

"Mennyire nem megbízható?"

A random hosting kornyezet? Semennyire. Attol, hogy valami "sajat", meg egyaltalan nem lesz "megbizhato".

"Here is a crypto library with a BSD licence, and a random number generator: crypto.stanford.edu/sjcl"

Ja, de ez ugy mukodik, hogy sajat maga gyujti az entropiat az egermozgasokbol. Ha a juzernek percekig rangatnia kell az egeret minden uzenetkuldes elott, az sok minden lesz, csak "_mindenki_ által egyszerűen és könnyen használható" nem.
(Egyebkent en arrol sem vagyok teljesen meggyozodve, hogy a felhasznalok tenyleg tudjak veletlenszeruen rangatni az egeret, ahelyett hogy pl. siman koroznenek vele).

"Az XSS-hez nem szerver oldali megoldás kellene?"

Nem.

"Elméletileg és rendkívül nehezen kihasználható sebezhetőségek figyelembe vétele számomra nem minden esetben jelentené a feladat reális nézőpontját."

Tudatosan hibakat hagyni egy biztonsagi szoftverben sulyos felelotlenseg, kulonosen ha a szakertelem nelkuli felhasznalo a cel, akiknek nem irhatod le a threat model-t 30 oldalban ("igen, biztonsagos, de csak akkor, ha...").

--
"You're NOT paranoid, we really are out to get you!"

"A lényeg az lenne, hogy kreálni egy _mindenki_ által egyszerűen és könnyen használható eszközt, amely a semminél _jóval_ nagyobb biztonságot adna úgy, hogy ne kelljen szoftvert telepíteni és ráadásul minden platformon működjön."

Es ha lehet, akkor meg fozzon kavet is, meg vigye ki a szemetet. Nem kivansz te kisse tul sokat?

Amugy abban sem erdemes bizni, hogy minden bongeszo kezel 2K meretu URL-eket, ugyanis ez semelyik szabvanyban nincs leirva (az URL szabvanya, az RFC3986 is csak annyit rogzit, hogy a hostnev resze nem lehet hosszabb 255 karakternel), ez csak egy un. de facto standard, vagyis iratlan szabaly. Erre szoftvert alapozni... hat... finoman es cizellaltan szolva is erdekes megkozelites. Mi van, ha holnap jon egy bongeszo, ami csak 1500 karaktert enged URL-eknek?
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

"Te nem vagy az adott szituban harmadik fél, mégis átadnád az adataidat, ha a [random ügynökség] elég szépen kérné. :D"

---> :D <---

Titkosítást pedig igenis használjunk, én is használok. A lokális megoldást TrueCrypt-nek hívják, a küldözgethetőt pedig GnuPG-nek. Akinek ez a kb. faék egyszerűségű eszköz bonyolult, az ne küldjön érzékeny adatot az interneten.

Ez esetben vállalom, hogy offtopic, amit leírtam. :)

A technológia úgy ahogy van szar - mármint melyik?
mérleg másik oldalán több évnyi letöltendő van - így van, ezért kapják a pénzt, lásd következő pontot
Könnyen bejutnak helyekre - ez szintén büntethető, és nem biztos hogy őket nehezebb elkapni mint két ismeretlen tettest
jönnek mennek adatok úgy, hogy soha meg nem tudod - ez ellen egy szintig lehet tenni, azon túl meg nem érdemes.
ha plain textbe megy - miért menne abban? Lásd első kérdés.

Már volt egy hasonló szál, úgy titkosítani valamit, hogy akkor se lehessen feltörni száz évig, ha cdmellkékletként osztogatják a csipmagazin mellé. A hasonlót úgy értem, hogy egy elméleti (nem létező?) problémára keres megoldást.

ha plain textbe megy mindig minden mindenhol. A két dolog között egy szakadék van sajnos.

Igen utóbbiban azt gondolod, hogy elég hátradőlni és minden okés pedig a plain text is lehet titkosított attól függetlenül, hogy "olvasható".

Egy ilyen elképzelés a titkosító index.html-el - szép css-el! - nagyon téves képzettársításokat generál.

0000000100000000000000000
0000100000010000000000000
0000000000010010000000000
0000000000000000000000000
0000000000000000000001000
0000000000000010010000000
0000000000010000000000000
0001000000000000000000000

(Hű mit írtam ide?^)

No rainbow, no sugar

"Ha két kopasz neked megy az adataidért, ott a mérleg másik oldalán több évnyi letöltendő van. Nem megy csak úgy büntetlenül."
Ha felhulyere vernek, akkor attol _neked_ nem lesz jobb, hogy ok hol es meddig ucsorognek. Megrendeloi szempontbol pedig szinten nem motivalo tenyezo. Innentol kezdve ez az erv irrelevans.

"Megint csak azt tudom mondani hogy legalább a semminél legyen valami több."

Mar most is van, fel lett sorolva, ott a DropBox peldaul. A semminel valamivel tobb, es ezzel pont megfelel a definicionak. Problem?
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Klasszikus érveléstechnikai hibák, menjünk sorba:

"Miért feltételezed, hogy az adataid érzékenysége időben nem változik? (Pl. volt időszak amikor olyan adatok miatt öltek embereket, ami előtte nem számított kényes adatnak.)"

Sehol se írtam ilyesmit. Ha valaki úgy véli hogy olyan titka van, amivel most ugyan senki se fogalkozik, de később az élete múlhat rajta, akkor az kezelje ennek megfelelően. A megfelelő kezelés egy apró részlete a titkosítás (lásd rosszul kitámasztott ajtó).

...posztolsz nyaralás közben képet, aztán hazaérkezve kirámolt lakás fogad.

Szintén egy szokásos para. Ha posztolok egy képet akkor nem marhára mindegy hogy amúgy titkosítva tárolom a pince alagsorában betokonckába öntve? Lásd előző pont, az érzékeny adatok megfelelő kezelése, és a következő pontot.

milyen infó segíti a gyerekedet becserkésző pedofilt, vagy a feleségedet meghódítani akaró riválist?

Valószínűleg nem tudom pontosan. Ilyenkor mi a jobb megoldás? Titkosítani mindent? Az aszonyt elküldeni plasztikai sebészhez, egy lakatlan szigetre költöztetni amit idomított cápák vesznek körül (dettó a gyereket) vagy a reális veszélyekre felkészülve foglalkozni velük? Mielőtt még elmenne mellékvágányra a vita, a gyereket/aszonyt épp úgy kileshetik az utcán, iskola környékén, szépségszalonban, strandon akkor is, ha a nyaralási fotókat még én se nézem meg, hanem egyből ledarálom egy blenderrel. Az ellen nem véd, hamis biztonságérzet, etc.

"Ez a lehetőség mindig adott"

Ezzel kezdtem a mondatomat, ha esetleg nem tűnt volna fel.

Vagy ez a kommented már a topikindító által emlegetett "jó irányba terelő trollkodás" akarna lenni? :)

Ha nincs SSL, és ha nincs védett hálózat, és ha az user így küld érzékeny adatot az ugye azért nem a rendszer hibája, a felhasználó(k) az idióta, idióták, kérem kapcsojja ki. Az ellen a JS-ben írt titkosítás se fog védeni.

Ha a szolgáltatótól akarod védeni az adatokat akkor lehet értelme a titkosításnak, de akkor megint jön a gonosz dolog, hogy a rendszer többi részét is hasonlóan ki kell gyúrni, mindkét oldalon. Már ha komolyan veszi az ember, hogy az ISP-m be akar törni hozzám és kotorászni akar a cuccaim között.

Ha nem a szolgáltatótól akarod védeni, hanem az oda betörőktől, akkor a helyzet pár nagyságrenddel súlyosabb.

Ha a probléma valós, akkor eleve az SMTP-t el kell felejteni vagy hiteles kulcsokkal aláírt leveleket szabad csak használni, hogy a felek egyértelműen azonosíthatóak legyenek és valami normális titkosítást használni a küldés, fogadás, tárolás, mentés, archiválás során az összes érintett gépen. Vagy inkább saját, zár rendszert, webmail-webmail felülettel, többszintű (kulcsos, OTP, miegyéb) azonosítással és természetesen a rendszert megfelelő helyen és módon tárolva. Ez már ad némi védelmet, de épp ez az amire kb. senkinek (magánszemélynek) nincs szüksége. Bár attól még jó móka kiépíteni.

+++++sok

Szerk:

// parameter is null?
if (secret == ""){

// ....

// handle enter on textbox of password to trigger click on button
function pass(event){
   if (event.keyCode == 13){
    go()
   }
}

Jujj. Ilyen kodot en akkor se adnek ki a kezembol, ha muszaj lenne. De hal' istennek, nem muszaj. Nem tudom, melyik kodnak ki a szerzoje, mert nincs melle odairva, de hat... kohhm. Pedig en tenyleg nem ertek hozza.
--

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. 

Meg nem, az encodeURI a '-t pont valtozatlanul hagyja.