Chrome on Melabit

Come riparare i segnalibri di Firefox

Mon, 16 Sep 2019 06:00:00 +0000

Sui miei Mac installo parecchi browser ma poi uso quasi sempre solo Firefox. Un po’ perché sono fedele, sono passato senza soluzione di continuità da Netscape a Mozilla a Firefox e non ho motivi seri per cambiare. E poi perché Firefox è multipiattaforma e può sincronizzare tutte le impostazioni e i dati personali (segnalibri, storia di navigazione, add-on, schede aperte, volendo anche le password) via cloud, una funzione utilissima quando si usano più Mac o si ha a che fare con computer e sistemi operativi diversi.

Certo, anche Google Chrome funziona ovunque, ma volete mettere il rispetto della privacy di quelli di Mozilla (la fondazione che supporta lo sviluppo di Firefox e del client di posta elettronica Thunderbird) con, diciamo così, la curiosità di Google?

Non che Firefox non abbia i suoi problemi. La ristrutturazione del codice di due anni fa ha reso il browser molto più veloce, ma purtroppo parecchie estensioni non sono mai state aggiornate per funzionare con il nuovo modello di codice (a me manca moltissimo ScrapBook che usavo per archiviare le pagine web e non sono ancora riuscito a rimpiazzarlo con qualcosa di altrettanto efficace).

E poi ci sono i segnalibri (bookmark per gli anglofili, preferiti per chi usa Safari). Se come me avete tanti segnalibri, non provate a sincronizzarli tramite il cloud di Firefox: è snervante, basta aggiungerne uno per innescare la sincronizzazione e intanto il browser rallenta in modo evidente. Per molto tempo, ad ogni nuova versione di Firefox ho sperato che ci fossero dei progressi in questo campo, ma poi sono sempre tornato a sincronizzare i miei segnalibri tramite Dropbox; la configurazione iniziale può essere un po’ fastidiosa, ma dopo va che è un piacere (varrebbe la pena riparlarne, prima o poi).

Firefox ha un problema ancora più serio con i segnalibri, che si presenta quando il browser va in crash. Ma prima bisogna fare una premessa.

Segnalibri e database

Da moltissimo tempo ormai Firefox salva i segnalibri in places.sqlite, un database SQLite che in macOS si trova nella cartella ~/Library/Application Support/Firefox/Profiles/abcd1234.default/ (come sempre ~ rappresenta la Home dell’utente). Questa cartella contiene tutti i file di configurazione e i database del browser, cioè il cosiddetto profilo dell’utente.¹ Il nome abcd1234.default della cartella del profilo utente è solo un nome generico, il nome reale è costituito da una sequenza casuale di otto lettere e numeri seguiti dalla stringa .default e viene generato quando usiamo per la prima volta Firefox sul nostro computer, oppure quando lo ripristiniamo per correggere eventuali problemi.

Nelle versioni più recenti di Firefox il nome di questa cartella segue un nuovo formato, abcd1234.default-1234567890123 (otto lettere e numeri seguiti dalla stringa .default, da un trattino - e da altri 13 numeri), ma il succo del discorso non cambia, per cui nel seguito continuerò ad utilizzare per semplicità il formato più vecchio (e più breve).

Il nome della cartella del profilo utente può essere ricavato dal Terminale con il comando

$ ls -al ~/Library/Application\ Support/Firefox/Profiles/

In alternativa possiamo selezionare da Firefox la voce di menu Aiuto → Risoluzione dei problemi oppure scrivere about:support nella barra degli indirizzi (Figura 1). Si apre una pagina che contiene parecchie informazioni utili, fra cui il percorso completo alla cartella del profilo, a cui si può accedere dal Finder cliccando sul bottone cerchiato in rosso (Figura 1). Da questa pagina possiamo anche ripristinare il browser o riavviarlo con le estensioni disattivate.

Figura 1. Strumento per la risoluzione dei problemi di Firefox.

NOTA Ricordo che da Windows 7 in poi (in effetti da Vista, ma chi lo usa ancora?), la cartella del profilo di Firefox si trova in C:\Users\<nome utente>\AppData\Roaming\Mozilla\Firefox\Profiles\, mentre in Windows XP è in C:\Documents and Settings\<nome utente>\Application Data\Mozilla\Firefox\Profiles\. Su Linux invece la cartella del profilo si trova in ~/.mozilla/firefox/, dove come in macOS ~ rappresenta la Home dell’utente.

Quando Firefox va in crash

Usare un database per gestire i segnalibri è molto efficace, soprattutto quando il numero di segnalibri memorizzati è piuttosto grande.² Inoltre, un database consente di implementare un meccanismo di sicurezza in base al quale tutte le operazioni da effettuare (inserimento di nuovi dati, cancellazioni, spostamenti e così via) vengono prima salvate in un file separato, che in Firefox si chiama places.sqlite-wal, per essere poi applicate al database principale places.sqlite solo al momento della chiusura del browser.³

Una volta conclusa l’operazione di aggiornamento di places.sqlite, il file places.sqlite-wal non serve più e viene cancellato. Quando eseguiamo di nuovo Firefox, il browser crea un nuovo file places.sqlite-wal in cui salvare le nuove modifiche ai segnalibri e il ciclo ricomincia.

Ma se Firefox in crash (ormai succede di rado ma succede), le modifiche contenute nel file wal non possono essere applicate al database places.sqlite. In genere non è un problema, al primo riavvio Firefox nota che places.sqlite-wal è ancora sul disco rigido e lo utilizza per aggiornare il database principale.

Purtroppo a volte qualcosa va storto, magari il crash avviene proprio mentre Firefox sta scrivendo nel file wal, magari Firefox si blocca e dobbiamo forzarne la chiusura, magari ci sono problemi durante la sincronizzazione dei segnalibri via cloud o via Dropbox, magari il file wal viene cancellato per sbaglio. In tutti i casi, l’effetto finale è che il database places.sqlite si corrompe e ci si ritrova con dei segnalibri scomparsi o con Firefox che fa i capricci. La funzione di ripristino del browser esiste anche per questo, basta usarla e tutto dovrebbe andare a posto, mantenendo inalterate tutte le impostazioni e i dati personali.

Ma un (brutto) giorno si lancia Firefox e si scopre di aver perso tutti i segnalibri…

Riparare il database

È proprio quello che è successo a me qualche settimana fa. Per fortuna Firefox fa periodicamente il backup dei segnalibri sul Mac, per cui possiamo sempre recuperare una versione precedente di places.sqlite perdendo al massimo le aggiunte degli ultimi giorni. E se per qualche motivo il backup di Firefox non funzionasse, c’è sempre la possibilità di recuperare le ultime versioni di places.sqlite da Time Machine, dall’account Dropbox o dal cloud di Firefox (per chi lo usa).

Ma che fine hanno fatto i segnalibri scomparsi? Andando a curiosare nella cartella del profilo (come già notato più sopra, lo si può fare dal Terminale con il comando cd ~/Library/Application Support/Firefox/Profiles/abcd1234.default/ seguito da ls -alh places*, oppure selezionando la voce di menu Aiuto → Risoluzione dei problemi e cliccando sul bottone Mostra nel Finder posto accanto alla voce Cartella del Profilo, come mostrato in Figura 1), oltre al solito places.sqlite si trova un altro file piuttosto grande, places.sqlite-corrupt. La dimensione di places.sqlite è decisamente piccola, troppo piccola per poter contenere tutto l’elenco dei segnalibri. È evidente che i veri segnalibri sono nel secondo file, quello che Firefox considera “corrotto”, mentre places.sqlite è solo un database quasi vuoto, generato automaticamente all’avvio da Firefox.

Quando è successo a me, la prima cosa che ho fatto è stata quella di ripristinare il browser creando un nuovo profilo, sostituendo poi il file places.sqlite generato automaticamente con la copia più recente che avevo su Dropbox. Firefox ha funzionato senza problemi per un giorno o due, poi ha deciso che places.sqlite era di nuovo corrotto e mi sono ritrovato di nuovo senza segnalibri. Chiaramente ci voleva una soluzione migliore.

La rete ha tutte le risposte, basta solo trovarle (cosa spesso non molto facile, dato il marasma di sciocchezze che si trova in rete). Ne ho lette tante, finché non sono arrivato all’articolo, places.sqlite Database Troubleshooting, contenuto nel sito ufficiale degli sviluppatori di Mozilla. L’articolo è molto chiaro, si vede che è scritto da gente competente, mi è bastato seguire pedissequamente le istruzioni per riparare il file places.sqlite e risolvere definitivamente il problema.

L’articolo però è scritto da sviluppatori per sviluppatori e presuppone che chi lo legge conosca perfettamente (o quasi) i comandi per gestire un database SQLite dal Terminale. In realtà proprio all’inizio viene citata una estensione piuttosto nota, Places Maintenance, che dovrebbe fare automaticamente quanto descritto nel testo. Ma il link non funziona più e quindi sembra che non ci siano alternative all’uso del Terminale.⁴

Ho deciso quindi di riportare le istruzioni presenti nell’articolo e di spiegare cosa fa ciascuna di esse, cercando così di rendere fruibile la procedura anche a chi non è molto esperto di Terminale o di database.

Le istruzioni commentate

Come già detto, per riparare places.sqlite bisogna usare necessariamente il Terminale. Chi non è pratico, prima di andare avanti farebbe bene a leggere le istruzioni di base per usare il Terminale sul Mac.

Prima di iniziare a lavorare è bene chiudere Firefox, in modo da evitare conflitti nel momento in cui ripristineremo la versione riparata del file places.sqlite.

Lanciamo il Terminale (come sanno bene i lettori più affezionati di questo blog, il Terminale si trova nella cartella Applicazioni → Utility), creiamo sul Desktop (o dove preferiamo) la cartella di lavoro fixplaces

$ mkdir ~/Desktop/fixplaces

e copiamo in questa cartella il file places.sqlite-corrupt dal nostro profilo Firefox, in modo da lavorare su una copia e non sul file originale

$ cp -p ~/Library/Application Support/Firefox/Profiles/abcd1234.default/places.sqlite-corrupt ~/Desktop/fixplaces

(naturalmente nel comando precedente bisogna sostituire a abcd1234.default il vero nome della cartella contenente il nostro profilo Firefox). Spostiamoci ora nella cartella di lavoro

$ cd ~/Desktop/fixplaces

e iniziamo il processo di riparazione del database. In macOS è installato di default il programma sqlite3, che permette di interagire dal Terminale con un database SQLite. Lanciamo sqlite3, facendo seguire al nome del programma quello del database su cui deve operare

$ sqlite3 places.sqlite-corrupt
sqlite&#62;

Il prompt del Terminale diventa sqlite>, ad indicarci che siamo entrati in una sessione di lavoro SQLite.

La prima cosa da fare è controllare l’integrità del database contenente i segnalibri places.sqlite-corrupt, in modo da essere sicuri che ci siano veramente dei problemi

sqlite&#62; PRAGMA integrity_check;

Attenzione, non dimenticate mai di aggiungere il ; alla fine di ciascuna istruzione SQLite!

Se il controllo dell’integrità del database non da errori possiamo uscire dalla sessione SQLite con

sqlite&#62; .exit

(un comando SQLite puntato non ha bisogno del ; finale) e chiederci cosa possa essere successo (chissà, magari abbiamo trovato un baco e in quel caso faremmo bene ad avvisare gli sviluppatori di Mozilla).

Ma se Firefox considera corrotto il file places.sqlite-corrupt, è molto difficile che il controllo di integrità dia un esito positivo, per cui nella stragrande maggioranza dei casi dovremo andare avanti eseguendo

sqlite&#62; .clone places.sqlite

che clona il database corrotto places.sqlite-corrupt nel nuovo file places.sqlite e mentre lo fa ripara automaticamente la struttura delle tabelle. Fatto questo eseguiamo un ultimo comando

sqlite&#62; PRAGMA user_version;

che ci restituisce un numero intero NN (nel mio caso era 52) che dobbiamo segnarci da qualche parte perché ci servirà fra poco. Abbiamo finito di lavorare sul database places.sqlite-corrupt e quindi usciamo dalla sessione SQLite con il comando

sqlite&#62; .exit
$

che ci fa tornare al solito prompt di bash. A questo punto dobbiamo eseguire di nuovo il programma sqlite3, lavorando questa volta sul database clonato places.sqlite

$ sqlite3 places.sqlite
sqlite&#62;

Ripetiamo il controllo di integrità (la prudenza non è mai troppa),

sqlite&#62; PRAGMA integrity_check;

che questa volta dovrebbe dare esito positivo.

Siamo a buon punto, ma ci sono ancora dei dettagli da sistemare. Prima di tutto dobbiamo inserire nel database clonato il valore della variabile user_version, cioè il numero intero NN che ci siamo segnati poco fa

sqlite&#62; PRAGMA user_version = NN;

poi dobbiamo azzerare il file wal

sqlite&#62; PRAGMA journal_mode = truncate;

aggiornare la dimensione delle pagine in cui è suddiviso il file del database

sqlite&#62; PRAGMA page_size = 32768;

ripulire definitivamente la struttura del database

sqlite&#62; VACUUM;

e infine ripristinare l’uso del file wal

sqlite&#62; PRAGMA journal_mode = wal;

Abbiamo finito, per cui possiamo eseguire

sqlite&#62; .exit
$

e tornare di nuovo a bash. L’ultimissima cosa da fare è copiare il file riparato places.sqlite dalla cartella di lavoro al nostro profilo Firefox (prima di farlo non dimenticate di controllare che Firefox sia chiuso)

$ cp -p places.sqlite ~/Library/Application Support/Firefox/Profiles/abcd1234.default/

Finalmente possiamo eseguire di nuovo Firefox e, se non abbiamo fatto errori, ritroveremo di nuovo tutti i segnalibri. Quando siamo sicuri al 100% che tutto funzioni correttamente, possiamo cancellare il file places.sqlite-corrupt dal profilo di Firefox, tanto non ci serve più (e comunque c’è sempre Time Machine).

Conclusioni

Mettere le mani in un database non è una cosa semplice e mette sempre un po’ di ansia. Ma queste istruzioni sono davvero a prova di bomba (gli sviluppatori di Mozilla sanno il fatto loro), basta solo seguire le istruzioni con un po’ di attenzione e di pazienza e tutto dovrebbe andare bene. In caso contrario, segnalatemi i problemi nei commenti e farò il possibile per rispondere.

Per confronto, Safari salva i segnalibri in Bookmarks.plist, un file XML che si trova in ~/Library/Safari/, mentre Chrome usa un file JSON, Bookmarks, situato in ~/Library/Application Support/Google/Chrome/Default/. ↩︎
Le prime versioni di Firefox salvavano i segnalibri in un semplice file HTML, bookmarks.html. Il passaggio al database places.sqlite si è dimostrato una scelta azzeccata, ma all’inizio era stato accolto con parecchio scetticismo. ↩︎
Il suffisso wal sta per write-ahead logging, un tipo particolare di file di journaling. ↩︎
Una volta finito di scrivere l’articolo ho scoperto che Places Maintenance è stato integrato in Firefox e che per utilizzarlo basta andare quasi in fondo alla pagina about:support e premere il bottone Verifica integrità che si trova sotto l’intestazione Database Places (Figure 2 e 3). Avendo già risolto il problema tramite la procedura descritta nell’articolo, non ho però potuto verificarne l’efficacia.
Figura 2. Verifica dell’integrità del database dei segnalibri tramite lo strumento integrato in Firefox. Figura 3. Risultato prodotto dallo strumento di verifica dell’integrità del database dei segnalibri. ↩︎

Come usare Skype Web con Safari e Firefox

Tue, 12 Mar 2019 06:00:00 +0000

Uso pochissimo Skype, per comunicare o condividere file con amici o colleghi preferisco di gran lunga usare Slack. Per cui, quando ho letto che la nuova versione di Skype utilizzabile via browser rilasciata la settima scorsa supportava solo Edge e Google Chrome – rispettivamente il nuovo browser Microsoft che l’azienda di Seattle cerca disperatamente di far usare a qualcuno e il browser dominante con il quale non si può non fare i conti – ho scrollato le spalle e sono passato ad altro.

Ma dopo aver perso tutta la mattina per far funzionare di nuovo la mia installazione di Office per Mac dopo un banale crash di Excel, ho il dente avvelenato con Microsoft. E quando mi è capitata di nuovo sotto sgli occhi la notizia dell’incompatibilità di Skype Web anche con browser molto diffusi come Firefox o Safari, ho voluto provare di persona. E in effetti, se si prova ad aprire Skype Web con uno di questi browser, si ottiene l’ormai ben nota schermata di “Browser not supported”.

Fig. 1. Accesso a Skype Web “visto” da Safari.

Fig. 2. Skype Web “visto” da Firefox.

Sembra si essere tornati ai tempi dei siti “Ottimizzati per Internet Explorer”, che più che ottimizzati erano solo codificati in modo sciatto.

E proprio come succedeva ai tempi del famigerato Internet Explorer, con un trucco semplicissimo è possibile rendere Safari o Firefox (ma di sicuro anche Opera o qualunque altro browser moderno) pienamente compatibili con la versione web di Skype.

Il trucco è banale, basta accedere a Skype Web fingendo di usare Edge o Chrome. La chiave di tutto sta nello User Agent, una stringa di testo che il browser invia al server ogni volta che accede ad una pagina web, che contiene fra l’altro il nome e la versione del browser e del sistema operativo in uso.

Lo User Agent della mia versione di Safari per macOS è

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.3 Safari/605.1.15

mentre quello di Firefox è

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:65.0) Gecko/20100101 Firefox/65.0

Lo User Agent inviato dal browser non è scolpito nel marmo, anzi si può modificare piuttosto facilmente, ed è proprio quello che faremo per accedere a Skype Web da un browser non supportato.

Safari

Per modificare lo User Agent in Safari bisogna prima di tutto selezionare le Preferenze del browser, cliccare sul pannello Avanzate e attivare l’opzione Mostra il menu Sviluppo nella barra dei menu.

Fig. 3. Preferenze avanzate di Safari.

Una volta tornati alla finestra principale del browser, si clicca sulla nuova voce di menu Sviluppo, poi su User Agent per selezionare infine nella lista che compare Google Chrome o Microsoft Edge. Se ora si prova ad accedere a Skype Web, al posto dell’avviso “Browser not supported” compare la solita finestra di login della Microsoft, basta inserire i propri dati ed è fatta.

Fig. 4. Ora Skype Web è accessibile da Safari.

Firefox

Per modificare lo User Agent in Firefox non è possibile utilizzare le funzioni native del browser e quindi il processo è leggermente più complicato. Ma Firefox ha add-on per (quasi) tutto, e fra questi gli add-on che modificano lo User Agent non mancano di certo.

Io uso User-Agent Switcher che funziona senza problemi ed è molto configurabile (fin troppo!), ma qualunque add-on analogo va altrettanto bene. Una volta installato User-Agent Switcher, sulla barra principale di Firefox compare l’icona di un omino con il cappello, basta cliccarci sopra per far comparire una lunghissima(!) lista di User Agent fra cui scegliere.

Fig. 5. La lista, fin troppo dettagliata, di User Agent supportati da User-Agent Switcher.

A questo punto basta selezionare lo User Agent di una delle ultime versioni di Edge o di Chrome e cliccare su Apply. Se ora si prova ad accedere a Skype Web, ci si troverà davanti la finestra di login della Microsoft e, come già visto per Safari, una volta inseriti i propri dati si potrà usare Skype Web anche con Firefox.

Fig. 6. Ora Skype Web è accessibile anche da Firefox.

Conclusioni

Rendere una applicazione web compatibile solo con alcuni browser è una mossa incomprensibile, anche perché taglia fuori una fetta più o meno larga di utenti del web.¹

Ma una volta risolto il problema della compatibilità di Skype Web con i browser non supportati ufficialmente da Microsoft, rimane il problema di fondo: ha senso continuare ad usare un programma come Skype che, se agli inizi era un prodotto innovativo, una volta passato nelle grinfie di Microsoft è peggiorato visibilmente, diventando ad ogni nuova iterazione sempre più grosso, pesante e poco pratico? Le alternative ci sono, perché non provare a cambiare?

Ancora meno comprensibile è che si possa aggirare il blocco così facilmente, non posso credere che gli sviluppatori Microsoft non conoscano questi trucchi banali. ↩︎

Apple o non Apple, questo è un problema

Tue, 25 Apr 2017 06:00:00 +0000

L’abbiamo letto e sentito (e magari anche detto) mille volte: per evitare che ci vengano carpite in modo fraudolento informazioni personali riservate – login e password di servizi importanti, dati della carta di credito, informazioni bancarie – è fondamentale controllare sempre che l’indirizzo (URL) del sito riportato nella barra degli indirizzi del browser sia quello legittimo.

Infatti, anche se per un qualunque malintenzionato è piuttosto facile creare un sito fittizio identico a quello legittimo, quello che non può riprodurre è proprio l’URL del sito, che è attribuito in modo univoco ed è gestito da un singolo database distribuito in tutto il mondo.

Un malintenzionato potrà quindi anche ricreare in modo perfetto l’aspetto del sito di PayPal, http://paypal.com, ma dovrà per forza di cose usare un URL leggermente diverso, magari http://pay.pal.com, http://mypaypal.com, o simili, sperando che il malcapitato che ci finisce non se ne accorga. Basta quindi un po’ di attenzione per evitare problemi.

Almeno finora.

Provate ad inserire nella barra degli indirizzi del vostro browser questo URL apparentemente inoffensivo, https://www.xn–80ak6aa92e.com.

Se usare Firefox, Opera o Chrome (fino alla versione 57.x), quando premete Invio siete portati ad un sito web il cui URL sembra essersi trasformato quasi magicamente in quello di Apple.

A questo punto, basterebbe riprodurre l’aspetto del sito di Apple per rendere il sito finto praticamente indistinguibile da quello legittimo, con gravissimi pericoli per la sicurezza dei malcapitati che dovessero finirvi.

Per fortuna, Safari non è soggetto a questo problema e mostra sempre nella barra degli indirizzi l’URL originale. Anche i browser Microsoft, Edge e il venerabile Internet Explorer, sono immuni, a meno di non usare il Russo come lingua di sistema.

Il bug è legato all’uso dei caratteri unicode per gli indirizzi web, o meglio alla rappresentazione dei caratteri unicode tramite i soli caratteri ASCII (detta rappresentazione punycode).

L’URL https://www.xn–80ak6aa92e.com/ rappresenta delle lettere dell’alfabeto cirillico che sembrano identiche (o quasi) a quelle dell’alfabeto latino, ma che rimandano ad indirizzi web completamente diversi da quelli originali.¹ La stessa cosa si può fare anche con altri alfabeti che hanno lettere simili alle nostre, fra cui il greco e l’armeno (anche se mi sembra per quest’ultimo le letetre simili siano veramente poche).

I dettagli tecnici del bug si possono leggere qui.

Quello che mi preme di più è spiegare come proteggersi. Perché è chiaro che inizieranno prestissimo degli attacchi basati su questa debolezza della codifica unicode, attacchi molto più pericolosi e difficili da smascherare di quelli che abbiamo dovuto subire finora.

Come già detto, Safari, Edge ed Internet Explorer non sono a rischio. Per chi usa Chrome, basta aggiornare alla versione 58.x appena rilasciata. Per Opera non è chiaro cosa succederà, ma comunque Opera ha una quota di utenti relativamente ridotta rispetto agli altri due browser a rischio.

Il vero problema è Firefox. Perché gli sviluppatori di Firefox hanno annunciato che cambiare il comportamento di default del browser creerebbe problemi agli “utenti le cui lingue non usano l’alfabeto latino” e che invece “loro vogliono che tutte le lingue e gli alfabeti siano trattati allo stesso modo su internet”.

Un intento nobile, ma anche pericoloso. Per fortuna c’è la possibilità di cambiare il comportamento di default di Firefox, accedendo alle pzioni avanzate di configurazione del browser.

Per farlo, basta scrivere about:config nella barra degli indirizzi del browser e premere Invio. Comparirà una scritta bella grande che ci informa che l’operazione può invalidare la garanzia, compromettendo la stabilità, la sicurezza e le prestazioni del browser. Decisamente eccessivo. Non preoccupatevi e cliccate senza paura sul tasto che vi fa accettare il rischio.

Inserite ora la stringa punycode nella barra di ricerca in alto. Comparirà un unico parametro di configurazione, network.IDN_show_punycode, il cui valore di default è false. Fate doppio click su false, trasformandolo in true, e chiudete la pagina di configurazione. Da ora in poi anche Firefox si comporterà come Safari e sarete al sicuro da possibili attacchi di questo tipo.

Per ulteriori approfondimenti, consiglio di leggere prima di tutto l’articolo originale che descrive il problema, Phishing with Unicode Domains di Xudong Zheng. Molto interessante e dettagliato anche This Phishing Attack is Almost Impossible to Detect On Chrome, Firefox and Opera di Mohit Kumar, mentre Chrome And Firefox Adding Protection Against This Nasty Phishing Trick e Chrome and Firefox Phishing Attack Uses Domains Identical to Known Safe Sites, riportano altri due esempi di URL a rischio.

Se si guarda attentamente, la ӏ di apple visibile nella barra degli indirizzi non è proprio una l ma una lettera dell’alfabeto cirillico). ↩︎