So, you want to disable Java in your browsers?


Yesterday I read about a new Java 0-day exploit that allows executing arbitrary programs on victim computers just by accessing a Web page, without any confirmation from the users.

I need Java Runtime Environment for a very nice app that I use: Geogebra. This and some Yahoo! Messenger games (like Pool or Backgammon) were the only reasons I still keep JRE installed.
I really don’t need the Java plugin enabled in any browser and for major browsers this shouldn’t be a big issue. There are specific and documented ways for disabling Java.

A pretty tricky problem is that my browser of choice is Maxthon 3 (don’t ask me why) and disabling the Java browser plugin isn’t as easy via UI as in other browsers. Even if Maxthon supports two engines (Chrome and IE), it doesn’t expose advanced options (like about:plugins or about:config in other browsers) that would allow better plugin control.

So, the problem was finding a way to disable the Java plugin in Maxthon (and in my other browsers), but still keep the JRE installed in order to use it for Geogebra.

(Please note that I’m referring to Java, not JavaScript – these are two very different technologies. I’m pointing this out because searching the net for stuff like “how to disable Java in browser” I found quite a lot of results that actually referred to JavaScript. This is not the place to elaborate on the issue.)

The nicest trick I found for solving my problem was (now I’m assuming the reader has some prior knowledge of manipulating the Windows Registry… and that he’s using Windows):
(1) open the Registry Editor;
(2) in HKEY_LOCAL_MACHINE find (CTRL+F) the key named MozillaPlugins (its location varies based on OS architecture – 32/64 bit; ex. in Windows 7 64 bit the location should be HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\MozillaPlugins\);
(3) expand that key, export the keys named like @java.com/*;
(4) delete those java keys.

This single move disabled the Java plugin in Maxthon 3, Firefox 15 and Chrome 18. I didn’t bother for Internet Explorer, since I don’t use it (except for testing some of my Web apps). Note that disabling Java in IE affects the Yahoo! Messenger games mentioned above. Also note that by clicking a Java applet placeholder in Maxthon, even after deleting those registry keys, an empty dialog with two buttons is displayed (when you click on the left button the browser tries to retrieve the plugin from the Web).

After all those changes you might want to test your browser.

This is, of course, a quick and dirty fix for a 0-day situation, not a thorough solution.

www.scj.ro a primit o injecție cu SQL


Încercam să aflu ceva de pe saitul Înaltei Curți de Casație și Justiție (denumit, foarte românește, folosind inițialele de la Supreme Court of Justice… până la urmă We’re all living in America, nu?).

Lista de ședințe nu funcționează. Văzând ceea ce era afișat, bănuiam că vreun dorel nu a închis cum trebuie niște ghilimele prin sursă. Încerc să aflu despre ce e vorba și văd ceva și mai drăgălaș: <script src=”http://lilupophilupop.com/sl.php”></script&gt;. O căutare pe Google lămurește problema – injecție SQL. ECRIS (versiunea anacronică, din 2005, pentru Î.C.C.J.) se pare că e vulnerabil. Cam cât de romantic ar fi ca și ECRIS IV, folosit de restul instanțelor din țară, să aibă astfel de vulnerabilități?…

Curtea de Apel București se fălește deja cu un nou sait (se putea mai bine… părerea mea), pe când unul nou, funcțional și util și la Î.C.C.J.?

La mulți ani!

Completare (4 ianuarie 2012): S-a reparat.

Citește și:
ECRIS – este bun, dar poate fi și mai bun

ECRIS – este bun, dar poate fi și mai bun


E greu să-mi închipui cum m-aș fi descurcat fără o aplicație precum ECRIS. Telefoane sau, mai rău, deplasări la grefă doar pentru a afla termene, soluții, numere de dosar etc.?! Probabil că instanțele ar fi avut nevoie de linii telefonice robuste și de o suplimentare serioasă de personal, care să facă față volumului mare de solicitări mărunte venite de la părți, avocați, experți… Din fericire, nu e cazul. De câțiva ani buni funcționează „Portalul instanțelor de judecată”, iar la sediul instanțelor există infochioșcuri care permit accesul la informații privind dosarele. Cea mai recentă versiune (IV) a ECRIS (probabil „Electronic Court Record Information System”) a primit deja critici din partea grefierilor. Ca utilizator, aflat pe latura read-only a interfeței aplicației, am adunat câteva observații despre cum cred că ar putea fi îmbunătățită.

1. Feedback

Criticile, observațiile, sugestiile ar fi mai eficiente dacă ar și ajunge la persoanele/instituțiile potrivite (v. Ministerul Justiției și producătorul aplicației). Vechea cutie pentru sugestii și reclamații are un corespondent electronic ușor de pus în operă – v. issue tracking system – care ar face inutilă discutarea acestor subiecte pe bloguri sau forumuri. Bugtrackerele folosite în procesele de asigurare a calității în programare (v. unul în acțiune), pot fi deschise și utilizatorilor de aplicații puse la dispoziție de instituții publice (v. ECRIS, Revisal etc.); de altfel, bugtrackerele pot fi extinse și asupra altor procese, nu neapărat legate de o aplicație software – ex. relațiile instituțiilor publice cu cetățenii, consultarea publică privind legiferarea.

ECRIS poate fi îmbunătățit pe baza feedbackului primit de la utilizatori – indiciu: issue tracker.

2. Mai multe informații

Informațiile care se găsesc pe portal sunt mult mai sărace decât cele afișate la infochioșcuri. De pildă, la infochioșcuri este afișată lista cu denumirile înscrisurilor existente la dosar (e adevărat, adesea incompletă) și termenele la care acestea au fost depuse, componența completului de judecată, numărul soluției pronunțate de instanță etc. Asemenea informații nu apar, însă, și pe portal. În ambele locuri nu ar strica și o ordonare cronologică (descrescătoare) a termenelor.
Din moment ce pe listele de ședință sunt afișate numele judecătorilor și ale grefierilor de ședință, de ce asemenea informații nu ar putea fi afișate și pe Internet? Bineînțeles, atât pe lista de ședințe, cât și pe fișa fiecărei cauze, pentru fiecare termen. Aceste informații pot fi elegant completate cu numele procurorilor de ședință (acolo unde e cazul) și ale reprezentanților părților (avocați, consilieri juridici, simpli mandatari). Ar prinde bine și o coerență în privința redactării numelor (dacă judecătorul este menționat ca Ionel POPESCU, de ce inculpatul sau vreo altă parte ar apărea ca IONESCU Gigi?! scrierea cu majuscule a numelui de familie ar aduce claritate pentru nume precum Viorel Ion).

Un alt detaliu care ar putea reduce numărul de requesturi HTTP pe sait ar fi afișarea cât mai detaliată și ergonomică a informațiilor. De exemplu, scenariul tipic de utilizare (cel puțin pentru mine) e următorul:

  1. accesez adresa http://noulportal.just.ro/;
  2. selectez județul, apoi instanța, apoi dau click pe linkul „Dosare” din lateral;
  3. caut fie numărul de dosar, fie un nume al unei părți;
  4. dau click pe rezultatul dorit din listă.

În fișa dosarului astfel obținută nu este indicat completul, ca să nu mai vorbesc despre ora de începere a ședinței sau despre sala de judecată. Pentru a afla, totuși, completul, accesez lista de ședințe pentru data dorită, verific lista fiecărui complet cu specializarea căutată (și sunt, de regulă, mai multe complete de penal sau de civil; trebuie văzută lista fiecăruia pentru a ajunge la cauza căutată) și dau click pe numărul de dosar. Abia așa aflu informații despre complet și ora de început a ședinței.
În ceea ce privește indicarea sălii de judecată, o soluție simplă ar fi conceperea unei scheme unice la nivel național (ex. Sala 1, nu Camera xyz) și a unor panouri de orientare, astfel încât orice persoană citată să știe cu siguranță încotro să meargă, fără a mai fi nevoie de indicații primite de la personalul instanței și fără a trebui să se familiarizeze cu obiceiurile administrative de acolo.

Navigarea pe portal în prezent e destul de unidirecțională și liniară. Un sistem simplu de breadcrumbs ar putea ajuta la orientare și la acces mai rapid la informații. De asemenea, starea curentă a cauzelor trebuie descrisă mai bine. De pildă, fișa unei cauze de la instanța de fond poate conține un link către fișa de la instanța din calea de atac (apel, recurs…), eventual cu menționarea părții care exercită calea de atac și a datei.

ECRIS ar putea afișa mai multe informații (indicativul completului de judecată, numele tuturor participanților în proces, sala de ședință, ora, calea de atac exercitată), într-un mod mai ergonomic.

3. Publicarea tuturor hotărârilor

Printre lamentările obișnuite în legătură cu justiția românească se află și cea privind practica neunitară – posibilitatea (adesea concretizată) ca două instanțe diferite (uneori, chiar două complete diferite ale aceleiași instanțe) să pronunțe soluții diferite asupra unor probleme similare. Primul pas spre un remediu ar fi să se cunoască practica (toată practica și numai practica…). Hotărârile sunt redactate folosind calculatoare. În paralel cu forma lor imprimată pe hârtie, pe portal ar putea fi foarte bine afișate cu link de download, în dreptul fiecărui termen de judecată.
Mă refer aici la toate hotărârile, indiferent de denumirea lor (încheieri, sentințe, decizii – v. articolul 255 din Codul de procedură civilă și articolul 311 din Codul de procedură penală).

Dispozitivul fiecărei hotărâri ar putea fi afișat în continuare pentru fiecare termen. E esențial ca acest dispozitiv să fie identic cu cel din documentul oferit spre descărcare. O rezolvare simplă ar fi: cu ajutorul interfeței grafice a ECRIS hotărârea este redactată pe părți (i.e. partea introductivă, considerentele, dispozitivul; numele și celelalte date fiind preluate automat din înregistrarea dosarului), iar datele sunt asamblate în funcție de cerințe (ex. toate părțile sunt exportate ca document; numai dispozitivul este afișat ca HTML).

Ar fi de preferat ca hotărârile să aibă un șablon unic (eventual, cu elemente grafice mai elaborate), să fie salvate într-un format precum PDF (mai dificil de editat) și să poarte semnătura electronică a membrilor completului de judecată (știu, asta sună deja a Star Trek…).

În acest fel nu numai că justiția ar deveni ceva mai transparentă și ușor de urmărit, dar s-ar atinge și obiectivul proiectului Jurindex (Toate hotărârile judecătorești pe Internet); v. și modelul francez. Simpla publicare a unor PDF-uri nu ar fi suficientă. Ar mai trebui ca sistemul să includă și un solid motor de căutare în baza de date și, eventual, o sortare inteligentă pe materii, faze procesuale etc.

ECRIS ar putea afișa toate hotărârile judecătorești (că doar toate poartă mențiunea că au fost pronunțate în ședință publică…) și semnate electronic, și indexate pentru a ușura documentarea juridică.

4. URL-uri simple, intuitive pentru dosare și pentru hotărâri

Un URL tipic folosit de portal arată cam așa: http://noulportal.just.ro/InstantaDosar.aspx?idInstitutie=54&d=MzA0MDAwMDAwMDAwMTExNTY*. Bun, putem identifica un query string cu un câmp idInstitutie care corespunde numărului de identificare al instanței stabilit prin regulamentul de ordine interioară al instanțelor, dar cel de-al doilea câmp (un număr codat în base64) este complet împotriva ideii de ergonomie și simplitate. Resursa respectivă poate fi accesată folosind un URL mai prietenos cu memoria și cu intuiția umană. Bunăoară, dacă numărul de dosar este 123456/12/2011, ce ar împiedica folosirea lui direct în URL (unul rescris mai simplu): http://portal.just.ro/d/123456/12/2011? (aici, d vine de la dosarul)

Dacă ar deveni vreodată posibilă accesarea hotărârilor pe Internet (v. punctul anterior), și URL-ul acestora ar trebui să fie simplu și intuitiv. O idee ar fi folosirea unei referințe relative la numărul de dosar, nu la numărul de ordine al hotărârilor instanței – ex. http://portal.just.ro/c/123456/12/2011/2 pentru a doua hotărâre din dosar. URL-urile mai scurte și mai intuitive ar fi utile și în cazul citării hotărârilor într-o lucrare scrisă. Comparați URL-ul folosit ca exemplu cu unul recomandat de C.E.D.O.:

http://cmiskp.echr.coe.int/tkp197/view.asp?action=html&documentId=824161&portal=hbkm&source=externalbydocnumber&table=F69A27FD8FB86142BF01C1166DEA398649

sau cu unul folosit de C.J.U.E.:

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:62009CJ0402:RO:HTML

Mai departe, cum ar fi dacă am putea fi ținuți la curent cu starea unui dosar prin RSS sau un serviciu web?

ECRIS ar putea folosi URL-uri simplificate, făcute intuitive și ușor de citat. ECRIS ar putea oferi informații în formate ușor de procesat prin mijloace electronice.

5. Fără numere de dosar atipice

Schema de numerotare a dosarelor este la prima vedere simplă: [număr curent]/[număr de identificare al instanței]/[an] (ex. 1234/56/2012). Cel puțin așa prevede articolul 992 din regulamentul de ordine interioară al instanțelor judecătorești.
Totuși, destul de frecvent pot fi întâlnite numere de dosar atipice, ornamentate cu alte componente – ex. dosarul 27259/215/2010*/a5 sau 16041..01/3/2008.

Dacă tot există un sistem clar de numerotare, care e justificarea pentru adaosurile atipice de asteriscuri, litere, cifre, după al treilea element al numărului de dosar?

ECRIS ar putea fi mai strict în ceea ce privește structura numărului de dosar.

6. Afișierul online

În anumite împrejurări, procedura prevede posibilitatea ca citarea să se facă la sediul consiliului local (articolul 177:4 din Codul de procedură penală) sau prin publicitate – la ușa instanței și în Monitorul Oficial sau într-un ziar mai răspândit (articolul 95:2 din Codul de procedură civilă). Evident, aceste proceduri sunt mai mult formale, nimeni nu se așteaptă ca persoana citată să compară doar pentru că și-a găsit numele printre colile A4 lipite cu generozitate și haotic la afișierul consiliului local sau printre însemnările deosebit de accesibile și gratuite din Monitorul Oficial, partea XYZ…

Probabil că afișarea pe Internet nu ar avea șanse semnificativ mai mari pentru ca procedura de citare să fie eficientă. Totuși, crearea unui afișier online, ca secțiune distinctă pe pagina fiecărei instanțe, ar putea avea o oarecare utilitate (oricum, implementarea ar fi una nedureroasă și necostisitoare – v. un exemplu pe saitul Curții Constituționale).

ECRIS ar putea afișa și citații în cazurile când se face citarea prin publicitate.

7. Comunicarea online

Iarăși Star Trek… Chiar recent citisem o știre despre respingerea ca tardivă a unei cereri de recurs trimise prin email. Codul de procedură civilă (articolul 1321:2) cuprinde mai nou posibilitatea încunoștințării părților prin mijloace electronice, iar Legea 455/2001 privind semnătura electronică prevede că în anumite condiții înscrisul semnat electronic „este asimilat, în ceea ce privește condițiile și efectele sale, cu înscrisul sub semnătură privată” (articolul 5). Totuși, aceste prevederi par a fi pur decorative din moment ce „sistemul” are o așa de mare aversiune față de comunicarea electronică.

Cum ar fi dacă fiecare parte ar primi din partea instanței (ministerului etc.), opțional bineînțeles, un certificat temporar emis exclusiv cu scopul de a-l folosi pentru semnarea documentelor comunicate în cursul procesului? De pildă, ca parte în proces solicit și primesc respectivul certificat, cu care semnez cererea de apel sau de recurs și o trimit instanței prin ECRIS. La fel de bine se pot depune și alte înscrisuri pe parcursul soluționării cauzei, fără a mai fi nevoie de coada de la registratură. Un model ar fi aplicația e-Curia a Curții de Justiție a Uniunii Europene.

Ar fi un început interesant…

ECRIS ar putea fi folosit și ca platformă de comunicare a actelor în cursul procesului.

8. Portal unic

Dintre instanțele judecătorești a căror activitate este reflectată pe portal lipsește Înalta Curte de Casație și Justiție. Aceasta are propriul sait, utilizând probabil o versiune mai veche a ECRIS (cu un IIS anterior lui .Net).
Deși în mod emfatic Curtea Constituțională este descrisă ca neaparținând autorității judecătorești, totuși ea funcționează după reguli familiare celorlalte instanțe (ex. ședințe publice, termene, citare). Ca și Î.C.C.J., Curtea Constituțională are propriul său mod (rudimentar) de afișare a informațiilor.

Nu ar fi decât în interesul publicului ca și activitatea acestor instanțe să fie reflectată în ECRIS, într-un mod unitar, coerent.

ECRIS ar putea include în mod unitar informații despre activitatea tuturor instanțelor, inclusiv a Î.C.C.J. și a C.C.R.

9. Performanța ECRIS

E de înțeles că și acum și pe viitor, traficul către portalul instanțelor de judecată va fi ridicat. Totuși, la sumele imense care apar în bugetele acestora (ex. în 2008 cheltuielile prevăzute pentru Tribunalul Dolj erau de 26.203.000 lei – peste 262 de miliarde de lei vechi…), e greu de crezut că nu se găsesc bani pentru servere mai acătării (care să nu fie îngenuncheate cu ușurința de acum) și pentru conexiuni în rețea cu viteză decentă.

ECRIS ar putea fi mai performant.

P.S. Nu puteam pierde ocazia de a semnala una dintre cele mai multiplicate greșeli de pe portal: „plângere contravetionala” – un -n- mâncat și niște diacritice scrise inconsecvent.

if ($anotimp == ‘toamna’){echo count($boboci);}


1. Hărțile circumscripțiilor instanțelor judecătorești din România

Încă de la începutul verii, cam în vremea „dezbaterilor” despre reorganizarea administrativ-teritorială a României, am terminat munca la două hărți la care m-am tot gândit încă din vremea când învățam pentru admiterea în barou despre competența teritorială a instanțelor. Este vorba despre o hartă a circumscripțiilor instanțelor civile și una a celor militare.

Hărțile ar fi urmat să ilustreze un articol de Wikipedia despre organizarea judiciară din România. N-am avut deloc inspirație să scriu ceva util, mai mult decât copy/paste din limba de lemn a textelor legale, așa că mă mulțumesc să public hărțile în speranța că poate altcineva își va cheltui o parte din timpul său pentru a scrie și ceva text.
Sper că așa va fi mai ușor de înțeles deosebirea între diferitele grade de jurisdicție: judecătorie < tribunal < curte de apel < Înalta Curte de Casație și Justiție.
Notă: Am inclus și modificările efectuate prin HG 868/2011 (MO 642/2011).

Descoperiri:

  • am aflat cu stupoare că existau destule instanțe numai în textul normativ, însă care nici după ani buni nu fuseseră înființate (ex. Judecătoria Bechet, Dolj); alte instanțe, precum Tribunalul Ilfov, nici azi nu sunt funcționale, în ciuda trâmbițatei înființări prin luna mai;
  • există, chiar și după desființarea unor instanțe, judecătorii cu circumscripții disproporționate ca suprafață – cf. Craiova vs. Adjud, Sinaia vs. Târgu-Jiu; există circumscripții cu forme neobișnuite (necontigue – Însurăței/Brăila, Huși/Vaslui; filiforme – Cluj-Napoca);
  • nu există o hartă oficială a unităților administrativ-teritoriale de nivel LAU 2 (municipii, orașe, comune) – cam așa arată ceea ce aș vrea să văd; baza pe care am folosit-o pentru trasarea limitelor comunelor este generată în GIS și folosește date mai vechi – așadar, e destul de probabil să existe mici erori în delimitări;
  • mai ales după anul 2000 harta administrativă a fost îmbogățită cu destule comune; împărțind electoratul sau doar realizând orgolii meschine („să fie și satul nostru un miez de comună!”) a fost împărțită și sărăcia – acum se plâng că nu au suficiente fonduri din impozite și taxe locale pentru a realiza ceva semnificativ în comună.
  • nu există o concepție unitară privind diversele diviziuni ale țării (ex. circumscripții de judecătorii, colegii electorale, circumscripții fiscale, silvice, circumscripții de curți de apel vs. regiuni de dezvoltare etc.).

2. forumgeografic.ro

Ideal era un CMS special conceput pentru reviste academice. Mi-a plăcut foarte mult Ambra (ex. PLoS One). Din nefericire, platforma pentru care a fost creat (Java) nu e suportată de hosting-ul nostru. Un alt obstacol semnificativ e modul de instalare (mult mai greu decât clica-clica obișnuit pentru CMS-uri populare). Pe locul doi în lista de opțiuni era Lodel. Marele lui neajuns a fost instalarea defectuoasă pe mașina de test (ex. cam prea multe deprecated-uri sâcâitoare pentru gustul meu). Am luat în calcul și OJS. Și el a dat câteva rateuri la instalare (ca și în cazul lui Lodel, codul nu e încă ajustat la PHP 5.x), dar putea fi făcut să meargă. Nu mi-a plăcut interfața îmbătrânită și extrem de „birocratizată” (are câte un tabelaș, câte un mesaj, câte o procedură pentru fiecare pas din peer review). Deși era tentantă și crearea unui CMS de la 0 în CodeIgniter, totuși a coda un întreg mecanism de autentificare, gestiune a conținutului, afișare etc. ar fi consumat enorm de mult timp pe care nu îl am la dispoziție.

… așa că am păstrat WordPress și am trecut la hăcuirea lui. Am renunțat la tema Atahualpa în favoarea uneia noi și (foarte) personalizate. Am adăugat noi plugin-uri, de departe cel mai util și frumos conceput mi s-a părut Codestyling Localization. Am adăugat noi funcții pentru lucrul cu taxonomii și custom fields, noi template-uri (pentru pagina de arhive, pentru paginile de cuprins, pentru pagina redacției – aici un simplu CSV exportat din OpenOffice.org Calc este procesat și afișat după șablon), generatoare de metadate Google Scholar și CrossRef. Datele bibliografice ale articolelor sunt trimise în JSON, iar de aici pot fi afișate în câteva formate de citare, dar și exportate ca file RIS și BibTeX. Am curățat baza de date de resturile de la teme și plugin-uri dezinstalate (wp_options păstra câteva sute bune de înregistrări complet inutile). Pentru orice funcție am încercat să nu stric prietenia cu qTranslate. Am păstrat URL-urile cât mai curate și intuitive (mai puțin folosirea id-ului pentru articole, în locul unui slug de lungime variabilă, adesea foarte lung). Am acordat puțină atenție și optimizării performanței (ex. caching, minification). Am vectorizat logo-ul făcut de Andra și am mai câștigat niște spațiu în partea de sus a paginii așezând logo-ul deasupra imaginii de fundal. A fost nevoie de un halou pentru ca logo-ul să fie vizibil indiferent de culoarea dominantă de sub el. Am modificat și șablonul Word pentru articole (sunt acolo și niște câmpuri care calculează prima și ultima pagină etc.).
Din perspectiva SEO saitul nu stă rău: un PageRank de 5 e decent (mai ales că până acum chiar nu m-a interesat SEO). Și Publish or Perish a început să raporteze indici din ce în ce mai buni (metadatele Google Scholar sunt responsabile aici).

Descoperiri:

  • PHP + collation + UTF-8 != ‘love’ – aveam nevoie ca autorii să fie ordonați alfabetic, într-un mod cât mai firesc (ex. Ț nu e între L și O, Î nu e înainte de B)… Totul se limita la sortarea unei array. N-am reușit să obțin ceea ce doream (și am încercat destule combinații de setlocale(), strcoll(), uasort() ș.a.m.d.). Până la urmă, cred că soluția cu care m-am consolat este cea mai bună, având în vedere că numele de autori pot avea inițiale cu diacritice neromânești (ex. Ž, Đ): ordonarea se face pe baza alfabetului latin, după ce caracterele cu diacritice sunt convertite în cel mai apropiat semn din setul ASCII;
  • trimiterea JSON dintr-un form – avem un query în baza de date, rezultatele ajung ca JSON într-o variabilă JavaScript, se pune problema folosirii acesteia pentru a genera local și oferi spre descărcare o filă (RIS, BibTeX…). Din cauza numeroaselor limitări din felul în care browserele tratează JavaScript, dar și a faptului că soluția găsită (Downloadify) este dependentă de Flash 10, am renunțat la ideea generării locale a filei. Trebuia însă folosit JSON-ul deja generat. Problema e că trimiterea din form a JSON-ului ca obiect face ca serverul să primească, evident, un [Object] inutil. A fost nevoie, oricât de zgârcit aș fi, de trimiterea JSON-ului în dublu exemplar: ca obiect JavaScript, utilizat pentru afișarea în diferitele formate de citare, și ca text, utilizat ca valoare a unui hidden input pentru generarea pe server a filelor RIS/BibTeX;
  • formate de citare – când mi-am scris lucrarea de licență nu aveam idee despre cât de complicată e lumea asta a referințelor academice. În lipsa unor instrucțiuni clare și bine structurate din partea facultății, am imitat stilul de citare găsit în cărți și am crezut că e bine așa. Cât de mult mă înșelam… Fiind nevoit să afișez citările în formate diferite, am parcurs instrucțiunile din câteva manuale de stil. În Occident parcă e o întrecere în privința stilurilor de citare, care mai de care mai încâlcite și pretențioase. Sunt sute de stiluri pentru afișarea unui set relativ restrâns de date (ex. autori, titlu, an, publicație…). Am întâlnit felurite mofturi ridicole – ex. în minunatul stil Turabian (de fapt, Chicago cu variațiuni) numele primului autor e scris inversat (Nume, Prenume), dar restul numelor de autori sunt enumerate în ordinea obișnuită (Prenume Nume; mulțumim, Kate Turabian!); în stilul APA, acolo unde sunt peste șapte autori, sunt enumerați primii șase, se adaugă „. . .” și apoi ultimul autor (dacă o lucrare are opt autori, cel de-al șaptelea e un ghinionist pentru că numele lui e înlocuit cu „. . .”). Am mai auzit și de mofturi de-a dreptul revoltătoare din folclorul academic autohton – ex. prenumele autoarelor s-ar scrie complet, pe când prenumele autorilor ar fi reprezentat prin inițială.
    Noroc cu formatele text de tip RIS/BibTeX. Datele lor pot fi importate în aplicații precum Zotero și apoi afișate într-o mulțime de stiluri, fără ca utilizatorul să fie nevoit să știe reguli aberante;
  • conversie UTF-8 în entities – am găsit o excelentă soluție, utilă pentru encodarea caracterelor UTF-8 în XML.

Criptografia cu chei publice, explicată prin ilustrații


Înainte de a discuta probleme juridice privind semnătura electronică am socotit că ar fi utilă explicarea intuitivă a unor noțiuni tehnice. Așa a apărut articolul Criptografia cu chei publice, explicată prin ilustrații, publicat pe novit.ro. O imagine valorează cât o mie de cuvinte… :)

***

Înțelegerea noțiunilor de bază despre criptografia cu chei publice, deja descrise de Ovidiu, poate fi înlesnită de câteva ilustrații simple privind (1) comunicarea criptată folosind PKI (Public-Key Infrastructure sau infrastructura de chei publice) și (2) semnarea electronică utilizând certificate digitale.

Câteva noțiuni importante

Înainte de prezentarea ilustrațiilor, este important să stabilim semnificația unor noțiuni utilizate:

  1. criptare: o operație prin care un mesaj poate fi transformat prin intermediul unui algoritm și al unei chei, astfel încât să devină neinteligibil pentru orice persoană care nu cunoaște cheia;
  2. decriptare: operația inversă criptării, prin care un mesaj deja criptat poate fi transformat prin intermediul unui algoritm și al unei chei, astfel încât să redevină inteligibil;
  3. cheie publică – cheie privată: o pereche de numere generate prin algoritmi matematici pornind de la un număr prim foarte mare; principala proprietate a acestor chei este posibilitatea de a folosi una dintre ele pentru a cripta un mesaj, iar pe cealaltă pentru a decripta mesajul rezultat; cheia publică este accesibilă teoretic oricui, în vreme ce cheia privată este păstrată în secret de titular;
  4. certificat digital: un fișier cu o structură standardizată, care este emis cu scopul de a atesta identitatea unei persoane;
  5. funcție hash: un algoritm matematic prin care pornind de la un mesaj cu o lungime oarecare se poate genera un șir de caractere (hash) de lungime fixă, care are proprietatea de a fi strict dependent de conținutul mesajul, orice modificare în mesaj ducând la generarea unui hash complet diferit; asemenea funcții sunt utile pentru a genera „amprente electronice” prin care se poate verifica foarte ușor integritatea mesajelor.

Comunicarea criptată folosind PKI

În ilustrația alăturată cele două personaje frecvent menționate în exemplele din domeniul criptografiei (Alice și Bob) doresc să comunice într-un mod care să asigure confidențialitatea. În partea din stânga a ilustrației este prezentat un scenariu ideal în care Alice îi transmite lui Bob un document pe suport de hârtie, iar în partea dreaptă este descris modul în care ar funcționa comunicarea prin mijloace electronice între cei doi. Analogia celor două scenarii este, sper, ușor de observat. Bineînțeles, datele sunt prelucrate cu ajutorul programelor instalate pe calculatoarele celor doi utilizatori (ex. editoarele de text).

Comunicarea confidențială: forma „clasică” în comparație cu forma electronică (clic pentru mărire).

Semnarea electronică utilizând certificate digitale

Semnarea electronică a documentelor, utilizând certificate digitale, se bazează pe proprietatea unei chei dintr-o pereche de tip cheie publică – cheie privată de a decripta ceea ce a fost criptat cu ajutorul cheii corespondente. Cu alte cuvinte, ceea ce a fost criptat cu cheia privată poate fi decriptat cu ajutorul cheii publice (și invers). De asemenea, semnarea electronică utilizează și funcțiile hash pentru a produce eficient amprenta electronică a unor documente, indiferent de dimensiunile acestora. Iată ilustrarea procedeului:

Semnarea electronică folosind un certificat digital și verificarea semnăturii (click pentru mărire).

A fost un articol util? Ce părere aveți? Această prezentare oarecum tehnică va fi urmată de o expunere a problemelor juridice legate de semnătura electronică.

Notă: Elementele grafice utilizate sunt preluate de la adresa http://pixel-mixer.com/ (mențiunea autorului fiind „These icons are free for commercial use. A link to pixel-mixer.com is required. Otherwise, please purchase a commercial license for 35$.”).

Citește și:
Implicații juridice ale filtrării și monitorizării Internetului în relația de muncă (novit.ro)

Nazi sanitizer


Scenario: simple Web application (written in PHP) needing some custom handling of the user input (it relies only on POST and ignores GET data; CodeIgniter style…). It already has a client-side validation mechanism that warns the user about the proper data types it expects, but cannot enforce any rule. A server-side validation would be cumbersome since the form has well over 100 fields, so pushing back the same page for a minor mistake isn’t an option. Now, the expected data types are pretty custom – some fields should only contain a typical name (like only letters, spaces, dashes, periods, or 0), others should have only an integer value from a specified range (like the ones in array(0 => ‘first value’, 3 => ‘second value’)), while some fields should represent the value of a checkbox.
All this data needs to be submitted to a database.

Trouble
First of all, there’s no guarantee that all the input fields are actually posted. If the database handler (say, a model) receives an incomplete set of values, it will likely crash because some variables it expected weren’t defined. So, the submitted data must be complete, or “normalized” to some default values.

Secondly, the application needs to handle the input so that it matches the expected types. Continue reading

Aventuri de sysadmin


Românul are o vorbă: nevoia te învață. N-a fost vreun vis de-al meu să devin sysadmin. Nici nu sunt. Însă se mai întâmplă uneori să dau de probleme necunoscute până atunci, pe care trebuie să le rezolv. Repede și definitiv. Și cum îmi place să văd în orice problemă o provocare pentru care sunt dispus să aloc cantități semnificative de timp și efort, trec imediat la treabă.

Pe la începutul lui iunie, într-o inspecție de rutină a unuia dintre saiturile pe care le-am creat și le administrez am descoperit niște lucruri nu tocmai drăguțe: tabard27.html, floor13.html (cu tot cu JavaScript de redirectare) și tabard27.jpg, floor13.jpg în htdocs (server Windows 2003 cu WAMP; nu am avut de ales în privința platformei). Știam prea bine că nu au ce căuta acolo așa că imediat am intrat în alertă. Caută pe net despre ele, vezi unde duc, caută în log-uri etc. După ce le-am șters nu am făcut nicio schimbare la configurația serverului pentru a observa cum se comportă (aparent, nu erau “chemate” de conținutul saitului – bazat pe WordPress; m-am hotărât să le observ). Log-ul de acces al Apache era plin de scan-uri:

92.243.17.* - - [28/May/2010:17:04:27 +0300] "GET /roundcubemail/README HTTP/1.1" 404 12030
92.243.17.* - - [28/May/2010:17:04:28 +0300] "GET /rc/README HTTP/1.1" 404 12019
92.243.17.* - - [28/May/2010:17:04:28 +0300] "GET /webmail/README HTTP/1.1" 404 12024
92.243.17.* - - [28/May/2010:17:04:29 +0300] "GET /roundcube/README HTTP/1.1" 404 12026
92.243.17.* - - [28/May/2010:17:04:30 +0300] "GET /mail/README HTTP/1.1" 404 12021
92.243.17.* - - [28/May/2010:17:04:30 +0300] "GET /README HTTP/1.1" 404 12016
...
82.196.2.* - - [29/May/2010:07:54:49 +0300] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 226
82.196.2.* - - [29/May/2010:07:55:11 +0300] "GET /phpmyadmin/main.php HTTP/1.0" 403 221
82.196.2.* - - [29/May/2010:07:55:11 +0300] "GET /db/main.php HTTP/1.0" 404 11518
...
195.207.15.* - - [29/May/2010:12:41:17 +0300] "GET /e107_files/e107.js HTTP/1.1" 404 11222
195.207.15.* - - [29/May/2010:12:41:18 +0300] "GET /e107/e107_files/e107.js HTTP/1.1" 404 11227
79.190.115.* - - [29/May/2010:15:44:52 +0300] "GET /thisdoesnotexistahaha.php HTTP/1.1" 404 11229

Filele buclucașe reapăreau într-o anume succesiune:

82.139.152.* - - [28/May/2010:23:22:45 +0300] "GET /tabard27.html HTTP/1.1" 404 9612
180.227.212.* - - [28/May/2010:23:22:48 +0300] "GET /tabard27.jpg HTTP/1.1" 404 9611
217.219.221.* - - [28/May/2010:23:23:58 +0300] "GET /floor13.html HTTP/1.1" 200 89

Cumva, după request-ul primei perechi, în care era returnat “page not found”, apărea ca prin minune floor13.html (200 HTTP). N-am reușit să găsesc vulnerabilitatea (să n-aud că e Windows-ul! :) ), așa că am trecut la închis toate portițele (“reducerea suprafeței de atac”). De ce n-am făcut asta mai din timp? Pentru că nu eram sysadmin, doar un dezvoltator Web.
Am schimbat permisiunile pe server în mare parte la read-only și am oprit un FTP (din IIS 6) pe care îl lăsasem pentru a lucra la sait prin FileZilla. Problemă rezolvată.

O altă distracție, foarte recentă, e cea cu un alt sait al meu. Acolo văd un număr uriaș de vizite care păreau a lua la rând toate link-urile (chiar mă interesează să nu facă asta, din mai multe motive; am și specificat în licență interdicția…). Când mă uit mai atent la datele vizitatorului curios, văd că e de fapt un crawler și încă unul care nu dădea doi bani pe robots.txt. În plus, în referer-uri văd și adresa locală în care își salva saitul meu. “I kill you until you die from it!”
Caut, așadar, despre cum să mă folosesc de .htaccess pentru a rezolva problema mea. Câteva reguli (ex. Deny from…, RewriteCond…, RewriteRule…), niște teste rapide și gata. Următorul!