Archives For about:config

Prima c’è stata Always Right, poi con l’arrivo di Firefox Quantum nel ramo Nightly sono passato a Open Tabs Next to Current, un componente aggiuntivo che ha sempre svolto quell’eccellente e per me irrinunciabile mestiere di aprire nuove schede ponendole alla destra di quella che ho utilizzato fino a un secondo prima. Non è però una novità che da qualche rilascio a questa parte, Firefox abbia finalmente scelto di includere una nuova voce di about:config dedicata a questa opzione, rendendola nativa.

Sicurezza: la 2-step verification di Firefox

Il componente aggiuntivo, per chi ancora non potesse o volesse sfruttare l’opzione nativa, è ancora disponibile su AMO (oltre che sulla pagina ufficiale di GitHub):

Open Tabs Next to Current
Open Tabs Next to Current

Ma è lo stesso autore, Sebastian Blask, a informare i suoi utenti che la storia del componente aggiuntivo può considerarsi conclusa:

After the addition of the browser.tabs.insertAfterCurrent setting in about:config you do not need this extension anymore.

vedi: github.com/sblask/webextension-open-tabs-next-to-current#note-for-firefox

Puoi operare la modifica tu stesso, aprendo l’about:config e andando quindi a cercare la voce browser.tabs.insertAfterCurrent, impostandola a True.

Firefox: è ora di dismettere Open Tabs Next to Current

La modifica è immediata, non hai bisogno di riavviare Firefox e potrai immediatamente godere della novità.


Se ne parla anche su r/firefox: reddit.com/r/firefox/comments/ainzny/open_tabs_next_to_current_addon_is_now_redundant

Condividi l'articolo con i tuoi contatti:

Lo sviluppo di Firefox (prevalentemente in versione Nightly, che arriverà poi in rilascio stabile dopo qualche settimana) è un continuo fermento di novità dovute a esperimenti o richieste che finalmente entrano in porto e vengono rese disponibili dopo insistenti richieste della comunità, è un po’ quel campo di battaglia dove tutto è ammesso e che non è detto che permetta a tutto di passare allo step successivo. In seguito al precedente articolo (Firefox Nightly: un paio di novità in arrivo) ci sono un paio di ulteriori novità in arrivo di cui possiamo certamente parlare (in parte già rilasciate a chi usa Nightly), e che andranno sicuramente a colpire l’utenza intera nel futuro prossimo del browser libero di casa Mozilla. Nel frattempo, se non te ne fossi accorto, la versione stabile di Firefox è arrivata alla 65 (vedi: twitter.com/Gioxx/status/1090275327299993600).

Firefox: Addio agli screenshot, benvenuto nuovo about:config!

Addio a Firefox Screenshot

Decisamente annunciato e facente parte dello shutdown del progetto Test Pilot (vedi: blog.mozilla.org/press-it/2019/01/15/levoluzione-nella-cultura-della-sperimentazione-di-firefox-un-grazie-dal-programma-test-pilot), Firefox Screenshot si avvicina al pensionamento. Non si tratta della funzione integrata all’interno del browser, quella continuerà a funzionare (con le riparazioni del caso), bensì il sito web che ospita oggi le catture schermo degli utenti che hanno deciso di salvare un’immagine e caricarla sui server di Mozilla, senza crearne una copia locale. Un colpo di forbice secco con il passato, al quale porre attenzione se si intende conservare qualcosa di precedentemente “bloccato nel tempo“, ti conviene farlo quanto prima per evitare brutti scherzi tra qualche settimana.

Nel frattempo puoi già modificare il comportamento della funzione di cattura schermata integrata in Firefox, per evitare che tu possa ancora caricare delle immagini online e dimenticarti di salvarne una copia sul tuo disco locale. Per farlo ti basterà passare dall’about:config e ritoccare un parametro della configurazione del tuo browser, per la precisione si tratta di extensions.screenshots.upload-disabled:

Firefox: Addio agli screenshot, benvenuto nuovo about:config! 2

La modifica è immediata e il risultato sarà grosso modo questo:

Firefox: Addio agli screenshot, benvenuto nuovo about:config! 3

Una svecchiata all’about:config

Calma e gesso, nessun drago è stato maltrattato durante questi esperimenti e il rinnovamento dei locali. L’about:config è una di quelle pietre miliari di Firefox che tutti gli utilizzatori hanno visto almeno una volta nella vita, a tratti abusato da chi non sa esattamente dove mettere le mani una volta aperto il cofano, è la stanza dei bottoni in grado di modificare ogni comportamento del prodotto Mozilla (ne beneficia anche Thunderbird, ma non solo). Sembra che qualcuno abbia ben pensato di prendere scopa, paletta, straccio e sgrassatore, dando un aspetto ben più lindo e giovane a ciò che ha sempre funzionato con il minimo sforzo estetico.

In attesa che l’aggiornamento raggiunga anche le altre versioni di Firefox oltre la Nightly, oggi puoi già dare un’occhiata a cosa accadrà nel prossimo futuro puntando il browser all’indirizzo chrome://browser/content/aboutconfig/aboutconfig.html (solo da Firefox Nightly, nda) e accettando di trovarti faccia a faccia con i draghi della stanza dei bottoni, è qui che tutto comincia, ancora una volta.

 

Il sistema è certamente più ordinato e semplice da utilizzare, anche se può rallentare un pelo sulle configurazioni hardware più datate. Non preoccuparti però, non costituisce attualmente la visualizzazione predefinita e anche quando lo sarà, Mozilla manterrà per qualche tempo la possibilità di passare dalla “via vecchia“, richiamandola tramite l’indirizzo chrome://global/content/config.xul.


crediti: techdows.com/2019/01/the-firefox-new-about-config-page-built-on-html-looks-so-cool-on-nightly.html

Condividi l'articolo con i tuoi contatti:

Il tweet è vecchio così come l’argomento, eppure ogni tanto torna in auge e non è mai per un buon motivo, perché si parla di tentativi di phishing che vanno a buon fine e mettono così in pericolo i tuoi dati e la tua privacy. Oggi torno quindi a parlarti (per la prima volta però sul blog) di Punycode e dei domini che non corrispondono esattamente al vero.

Firefox e Punycode: occhio ai tentativi di phishing

Punycode

Se hai letto Punycode così come un ateo leggerebbe un passo della Bibbia (che poi non è detto), non preoccuparti, può anche starci che tu non conosca l’argomento e non sappia di cosa stiamo parlando. Viene in aiuto un articolo di qualche mese fa, pubblicato all’indirizzo dev.to/loganmeetsworld/homographs-attack–5a1p, all’interno del quale viene minuziosamente spiegato come è possibile “attaccare” un ignaro utente di Firefox (ma anche Chrome e altri browser) sfruttando l’interpretazione dei caratteri Unicode (come le emoji che siamo tutti abituati a usare nelle applicazioni di messaggistica istantanea).

Volendola riportare in breve, ti cito qualche riga della voce specifica su Wikipedia:

Punycode è un sistema di codifica definito nella RFC 3492 che serve a rappresentare univocamente una sequenza di caratteri unicode tramite una sequenza di caratteri ASCII, per rendere possibile l’uso di tali sequenze nei nomi di dominio, senza dover modificare infrastrutture e standard esistenti.

Continua su: it.wikipedia.org/wiki/Punycode

Ciò vuol dire che potresti tranquillamente utilizzare una emoji al posto del testo o, se preferisci (e come viene generalmente fatto per questo tipo di attacchi), una serie di caratteri ASCII che vengono poi letti e mostrati in maniera più chiara dal browser. Che significa di preciso? Presto detto: il tweet a cui facevo riferimento in apertura articolo è questo di seguito …

Firefox & Chrome

Ciò che a te sembra assolutamente identico tra lo screenshot superiore e quello subito sotto, nella realtà corrisponde a profonda differenza tramite Punycode: www.xn--twili-nye.com (e questo è solo un esempio con caratteri russi) riporta apparentemente a un sito web lecito, che di lecito però nella realtà non ha nulla. La medesima storia è già stata documentata ampiamente in passato, successe anche con il domino di Apple (quello che per tutti è Apple.com e che ancora oggi esiste ancora come PoC Punycode se dai un’occhiata all’articolo al quale ti porto tramite il collegamento inserito qualche parola fa), funzionante su qualsiasi browser aggiornato (vedi il mio, qui di seguito):

Il “Prima” e “Dopo” che leggi come descrizione delle immagini è dovuto alla modifica che su Firefox ho apportato ormai diverso tempo fa, proprio per combattere questo tipo di attacco e poter immediatamente avere massima visibilità di domini che utilizzano il Punycode. La modifica alla quale faccio riferimento riguarda ovviamente l’about:config del browser, più precisamente la voce network.IDN_show_punycode, descritta già nel 2006 nella Knowledge Base di MozillaZine (kb.mozillazine.org/Network.IDN_show_punycode), che contrariamente al predefinito booleano “false” può (e secondo me deve) essere impostata a true per mostrare i caratteri estesi che compongono il nome del dominio in maniera altrimenti più leggibile, proprio come nell’immagine di seguito (presa sempre dal mio Nightly):

Firefox e Punycode: occhio ai tentativi di phishing 3

Ed è così che è semplice arrivare alla situazione riportata dall’immagine qualche riga più su con la descrizione “Dopo“, è evidente che un attacco di questo tipo non potrebbe mai andare a buon fine. Se però preferisci agire in maniera diversa, puoi sempre pensare di fare uso di un componente aggiuntivo come PunyCode Domain Detection, italiano sin dalla nascita (realizzato da Francesco De Stefano) e disponibile chiaramente su AMO:

Che potrebbe avere un corrispettivo anche nel Chrome Store (no, non se ne è occupato sempre lui anche dall’altro lato) in Punycode Alert:

Punycode Alert
Punycode Alert
Developer: i3visio
Price: Free

In conclusione

Argomento di discussione da anni e motivo di critica verso chi ancora non ha portato sul tavolo regole ufficiali e valide per tutti, Punycode e possibilità di registrazione domini alquanto discutibili basati su caratteri estesi continuano a mietere vittime poco attente (o poco preparate, a volerla dire tutta), per questo motivo è bene prendere precauzioni in totale autonomia e muoversi sin da subito (in realtà bisognava averlo già fatto anni fa).

Quanto riportato sopra è frutto della mia personale esperienza e si tratta ovviamente di suggerimenti che sei libero o meno di applicare. Se nel tuo caso hai preferito intraprendere una differente strada e vuoi parlarne, sei assolutamente libero di farlo in area commenti, è sempre bello potersi confrontare e arricchire le pubblicazioni del blog (ormai dovresti conoscermi e saperlo bene).

Spero di non aver dimenticato nulla. In caso contrario, bussa e segnalalo, sarà mia premura metterci quanto prima una pezza ;-)

Buona navigazione!


Ulteriori fonti:

Condividi l'articolo con i tuoi contatti:

Firefox

Con Firefox in versione Nightly, dai un’occhiata “prima del tempo” a ciò che succederà nella versione stabile del browser di Mozilla, prendendoti rischi e pericoli per il tuo profilo e per la stabilità del browser stesso (ogni tanto può capitare che qualcosa si inceppi e venga risolta qualche ora dopo). Quella che è stata da poco introdotta è una di quelle novità “invasive” che potrebbero portare rogne all’utente medio, impattando sui suoi componenti aggiuntivi.

Come saprai, Firefox gira ormai in multiprocesso (wiki.mozilla.org/Electrolysis), permettendoti così di fruire di una navigazione più stabile e che più difficilmente va in crash come un tempo (e ti ricordo che spesso il problema era causato dai plugin, Adobe Flash in primis, e non certo dal browser in sé). Ulteriore novità verso la quale stiamo andando incontro, è la compatibilità con componenti aggiuntivi considerati obsoleti poiché non passati al nuovo standard Web Extensions (wiki.mozilla.org/WebExtensions). Se a questo aggiungi anche un (giusto, nda) impedimento nei confronti del funzionamento di componenti aggiuntivi non compatibili con la modalità multiprocesso, questo è il risultato:

Firefox: estensioni disattivate perché non multiprocesso

Fatta eccezione per Pushbullet, fuori uso nell’immagine ma in seguito aggiornato e nuovamente funzionante, gli altri componenti aggiuntivi sono rimasti KO fino a mio intervento. Questa mossa di Mozilla sta generando una “naturale selezione” che tenderà a pulire quello che è il più vasto catalogo ufficiale messo a disposizione degli utilizzatori del panda rosso, AMO (addons.mozilla.org).

Cosa sta succedendo in Nightly (e che quindi succederà nelle prossime versioni stabili del software) lo spiega direttamente Mozilla, in un articolo disponibile sulla Wiki ufficiale:

The Firefox team is currently focused on vastly improving performance in Firefox 57. Unfortunately, if you have add-ons installed in Nightly that are not WebExtensions, they make performance measurements on Nightly much harder. This is especially true of add-ons that are not multiprocess compatible and use shims.

Trovi maggiori informazioni (l’articolo è a oggi ancora in aggiornamento) all’indirizzo wiki.mozilla.org/Add-ons/ShimsNightly. Forse ti basterà sapere che, per ora, una modifica all’about:config ti permetterà di riportare in vita ciò che è stato automaticamente disattivato. Digita about:config nella barra dell’URL, premi invio e garantisci a Mozilla che farai attenzione a ciò che modificherai ;-)

Ora cerca la voce extensions.allow-non-mpc-extensions, e impostala a true, contrariamente a quanto presente di default (false, per ovvi motivi):

Firefox: estensioni disattivate perché non multiprocesso 1

La modifica è immediata, i componenti aggiuntivi si riattiveranno e –a meno che non abbiano bisogno di un riavvio del browser– saranno nuovamente operativi senza ulteriori operazioni da eseguire.

Cosa puoi fare nel frattempo? Cercare alternative ai componenti aggiuntivi utilizzati fino a oggi. Ti serve software che venga aggiornato e mantenuto nel tempo, in modo da soddisfare quelli che ormai sono i requisiti minimi (o consigliati) imposti da Mozilla, per rimanere al passo con i tempi e andare incontro alla continua evoluzione dettata spesso dalle esigenze degli utilizzatori stessi.

Vale ovviamente una giusta alternativa, quella che consiste nel contattare chi i componenti aggiuntivi li scrive, pregandolo di tenerli aggiornati, cosa che può anche succedere passando per AMO stesso, come per Xmarks (addons.mozilla.org/it/firefox/addon/xmarks-sync/reviews), mantenendo però la calma e tenendo a bada la lingua (o la tastiera, in questi casi). Giusto segnalare un malfunzionamento, ma con i modi corretti (e in inglese, consiglio spassionato). Io ho preferito contattare il supporto di LastPass (che possiede Xmarks) tramite il loro sistema di ticket, segnalando il problema (e ottenendo risposte che mi hanno lasciato intendere che l’helpdesk non conosca poi così tanto bene le varianti ufficiali di Firefox, ma tant’è).

Fai attenzione: con l’arrivo di Firefox 57 questa modifica sarà ufficialmente in produzione, senza riserve (salvo modifiche alla roadmap). Ricordati sempre che il forum di Mozilla Italia è sempre a tua disposizione in caso di problemi.

Condividi l'articolo con i tuoi contatti:

La primavera è già passata da qualche tempo, ma il mio evidente ritardo nel percepirla ha fatto slittare in avanti dei lavori di pulizia che rimandavo da troppo tempo. Il mio profilo principale di Firefox (costantemente replicato e sotto backup) conteneva dati davvero troppo vecchi, facendo arrivare alcuni dei database SQLite dell’applicativo a occupazioni disco fuori (e di molto) dallo standard al quale si è abituati nelle nuove installazioni (o nei profili più puliti). Per questo motivo ho scelto di prendere scopa, paletta e smacchiatore per dare un po’ più di piglio energico al browser di casa Mozilla, il predefinito sulle mie macchine.

Firefox: ottimizzazione dei DB SQLite 6

Ti spiego in poche parole (e diversi dati) ciò che ho fatto. Ti mando subito a leggere qualche riga riguardo SQLite nel caso in cui non sapessi di cosa si sta parlando, male non può certamente fare. I file incriminati e importanti sono sostanzialmente due: places.sqlite e webappsstore.sqlite. Prima di partire, una giusta cultura di base: il primo file (database, in realtà) contiene tutta la cronologia di navigazione in base ai criteri da te impostati all’interno delle opzioni di Firefox, non contiene i Segnalibri contiene i Segnalibri nella tabella moz_bookmarks, che viene toccata durante la pulizia solo per rimuovere spazi lasciati vuoti dall’utilizzatore (qui la pagina di KB su mozillaZine). Il secondo file invece conserva i dati che generalmente si vanno a compilare nelle form dei siti web che visitiamo, si tratta di un database molto delicato che non andrebbe mai modificato manualmente e che puoi permetterti di perdere solo se non ti secca ricominciare a creare una cronistoria dei dati che dovrai inserire a mano (per esempio) durante la registrazione di un modulo, una nuova iscrizione a chissà quale forum o così via (qui la pagina KB su mozillaZine).

Sia chiaro: Firefox continuerà a funzionare sulla tua postazione anche se cancelli completamente i due file, poi però non lamentarti se vai a perdere la cronologia di navigazione o i dati precedentemente immessi nei moduli (e non solo), di sicuro ci guadagni in velocità :-)

Io ho voluto clonare il profilo e mettere alla prova un’estensione che promette di andare ad alleggerire questi due file a patto di trovare delle voci orfane, quindi eliminabili in via definitiva, ricostruendo il database e popolandolo solo con le voci effettivamente vive e vegete (vedi: vacuum SQLite). L’estensione è Places Maintenance e la puoi trovare ovviamente su AMO:

Places Maintenance
Places Maintenance
Developer: Mak
Price: Free

Perché proprio lei in un mare di altre estensioni dedicate alla manutenzione dei database SQLite di Firefox? Perché è sviluppata da un amico connazionale e profondo conoscitore di Firefox, Mak, Firefox Team Engineering Consultant.

A installazione terminata (non richiede riavvio, nda) ho lanciato immediatamente una scansione della situazione sul profilo clonato, questo il risultato:

Statistics
 Database size is 81920 KiB
 user_version is 32
 page_size is 32768
 cache_size is -2048
 journal_mode is wal
 synchronous is 1
 History can store a maximum of 104858 unique pages
 Table moz_places has 104024 records
 Table moz_historyvisits has 281408 records
 Table moz_inputhistory has 469 records
 Table moz_bookmarks has 641 records
 Table moz_keywords has 0 records
 Table sqlite_sequence has 1 records
 Table moz_favicons has 4080 records
 Table moz_annos has 2192 records
 Table moz_anno_attributes has 13 records
 Table moz_items_annos has 172 records
 Table sqlite_stat1 has 15 records
 Table moz_hosts has 6291 records
 Index sqlite_autoindex_moz_inputhistory_1
 Index sqlite_autoindex_moz_keywords_1
 Index sqlite_autoindex_moz_favicons_1
 Index sqlite_autoindex_moz_anno_attributes_1
 Index sqlite_autoindex_moz_hosts_1
 Index moz_places_faviconindex
 Index moz_places_hostindex
 Index moz_places_visitcount
 Index moz_places_frecencyindex
 Index moz_places_lastvisitdateindex
 Index moz_historyvisits_placedateindex
 Index moz_historyvisits_fromindex
 Index moz_historyvisits_dateindex
 Index moz_bookmarks_itemindex
 Index moz_bookmarks_parentindex
 Index moz_bookmarks_itemlastmodifiedindex
 Index moz_places_url_uniqueindex
 Index moz_places_guid_uniqueindex
 Index moz_bookmarks_guid_uniqueindex
 Index moz_annos_placeattributeindex
 Index moz_items_annos_itemattributeindex
 Index moz_keywords_placepostdata_uniqueindex

Occhio a:

  • Database size is 81920 KiB
  • History can store a maximum of 104858 unique pages
  • Table moz_places has 104024 records
  • Table moz_historyvisits has 281408 records

Ho volutamente evidenziato i valori più importanti a livello di onerosità su database, ciò che più occupava il file SQLite era chiaramente il contenuto della mia cronologia, praticamente quasi mai resettata. Il valore massimo delle pagine uniche memorizzate nella cronolgia è fisso a 104858 poiché dettato da una configurazione di about:config, per l’esattezza si tratta di places.history.expiration.transient_current_max_pages.

Firefox: ottimizzazione dei DB SQLite 2

Ho lanciato un’ottimizzazione senza toccare alcunché, provando a lasciare invariato il contenuto della navigazione passata e ho dato un’occhiata ai risultati:

Statistics
 Database size is 71680 KiB
 user_version is 32
 page_size is 32768
 cache_size is -2048
 journal_mode is wal
 synchronous is 1
 History can store a maximum of 104858 unique pages
 Table moz_places has 104026 records
 Table moz_historyvisits has 281412 records
 Table moz_inputhistory has 469 records
 Table moz_bookmarks has 641 records
 Table moz_keywords has 0 records
 Table sqlite_sequence has 1 records
 Table moz_favicons has 4080 records
 Table moz_annos has 2192 records
 Table moz_anno_attributes has 13 records
 Table moz_items_annos has 172 records
 Table sqlite_stat1 has 15 records
 Table moz_hosts has 6291 records
 Index sqlite_autoindex_moz_inputhistory_1
 Index sqlite_autoindex_moz_keywords_1
 Index sqlite_autoindex_moz_favicons_1
 Index sqlite_autoindex_moz_anno_attributes_1
 Index sqlite_autoindex_moz_hosts_1
 Index moz_places_faviconindex
 Index moz_places_hostindex
 Index moz_places_visitcount
 Index moz_places_frecencyindex
 Index moz_places_lastvisitdateindex
 Index moz_historyvisits_placedateindex
 Index moz_historyvisits_fromindex
 Index moz_historyvisits_dateindex
 Index moz_bookmarks_itemindex
 Index moz_bookmarks_parentindex
 Index moz_bookmarks_itemlastmodifiedindex
 Index moz_places_url_uniqueindex
 Index moz_places_guid_uniqueindex
 Index moz_bookmarks_guid_uniqueindex
 Index moz_annos_placeattributeindex
 Index moz_items_annos_itemattributeindex
 Index moz_keywords_placepostdata_uniqueindex
  • Database size is 71680 KiB
  • History can store a maximum of 104858 unique pages
  • Table moz_places has 104026 records
  • Table moz_historyvisits has 281412 records

Un risparmio sicuramente interessante, ma sceso appena di –circa– 10 MB, ancora poco in confronto a un file che superava gli 80MB. Ho quindi scelto di mantenere esclusivamente gli ultimi 6 mesi di cronolgia di navigazione del browser, ottenendo (tramite lo stesso procedimento) un risultato nettamente più significativo:

Orphans expiration
 + Database cleaned up
 > Coherence check
 + The database is coherent
 > Vacuum
 Initial database size is 71680 KiB
 + The database has been vacuumed
 Final database size is 30720 KiB
  • Initial database size is 71680 KiB
  • Final database size is 30720 KiB

Un risparmio di circa 50MB rispetto al file originale, un sacrificio più che accettabile considerando che in 6 mesi ho certamente visitato siti web ai quali sono solito passare a fare un saluto, perdendo chi probabilmente non utilizzo così frequentemente (o non utilizzo più, tanto per farla più drastica). Il nuovo report fatto girare subito dopo il vacuum parla chiaro:

Statistics
 Database size is 30720 KiB
 user_version is 32
 page_size is 32768
 cache_size is -2048
 journal_mode is wal
 synchronous is 1
 History can store a maximum of 104858 unique pages
 Table moz_places has 40051 records
 Table moz_historyvisits has 55735 records
 Table moz_inputhistory has 165 records
 Table moz_bookmarks has 641 records
 Table moz_keywords has 0 records
 Table sqlite_sequence has 1 records
 Table moz_favicons has 2036 records
 Table moz_annos has 819 records
 Table moz_anno_attributes has 12 records
 Table moz_items_annos has 172 records
 Table sqlite_stat1 has 15 records
 Table moz_hosts has 3313 records
 Index sqlite_autoindex_moz_inputhistory_1
 Index sqlite_autoindex_moz_keywords_1
 Index sqlite_autoindex_moz_favicons_1
 Index sqlite_autoindex_moz_anno_attributes_1
 Index sqlite_autoindex_moz_hosts_1
 Index moz_places_faviconindex
 Index moz_places_hostindex
 Index moz_places_visitcount
 Index moz_places_frecencyindex
 Index moz_places_lastvisitdateindex
 Index moz_historyvisits_placedateindex
 Index moz_historyvisits_fromindex
 Index moz_historyvisits_dateindex
 Index moz_bookmarks_itemindex
 Index moz_bookmarks_parentindex
 Index moz_bookmarks_itemlastmodifiedindex
 Index moz_places_url_uniqueindex
 Index moz_places_guid_uniqueindex
 Index moz_bookmarks_guid_uniqueindex
 Index moz_annos_placeattributeindex
 Index moz_items_annos_itemattributeindex
 Index moz_keywords_placepostdata_uniqueindex
  • Database size is 30720 KiB
  • History can store a maximum of 104858 unique pages
  • Table moz_places has 40051 records
  • Table moz_historyvisits has 55735 records

Partito con un places.sqlite da più di 80MB e un webappsstore.sqlite da circa 101MB, mi ritrovo con 30MB circa di database cronologico ma un webappstore.sqlite ancora particolarmente obeso.

Ho cercato altri casi simili e mi sono imbattuto su una segnalazione di BugZilla: bugzilla.mozilla.org/show_bug.cgi?id=857888. È partita da un problema relativo a Firefox sul mondo Mobile, ma pare soffrirne anche la versione PC, come confermato anche da una discussione su Reddit (r/firefox)

PSA: Large webappsstore.sqlite file in your profile will heavily affect the responsiveness of Firefox’s UI from firefox

La scelta drastica? Rinominare il database webappsstore.sqlite per non farlo più trovare a Firefox (ovviamente chiuso) il quale lo ha creato da zero una volta riaperto, ho provato così a perdere la cronologia dei moduli e delle applicazioni utilizzate fino a quel momento:

Firefox: ottimizzazione dei DB SQLite 1

Il risultato? Ho utilizzato il profilo sul quale ho effettuato manutenzione per una settimana, ritenendolo adatto a diventare il principale perché la “perdita” non giustificava (secondo me) i rallentamenti sporadici del browser. Oggi sono fermamente convinto di aver fatto la scelta migliore, anche se fino a quando ci saranno siti web contenenti schifezze in Flash e simili, si continuerà ad avere un’occupazione importante del plugin-container.exe che permette a plugin (come quello Adobe) di girare in background, nonostante il Click-2-Play.

Occhio sempre a ciò che fai e dove metti le mani, ma mai abbandonare il tuo fido strumento di navigazione, potrebbe risentirne pesantemente la tua pazienza! ;-)

Ultimo aggiornamento: 5/7/16 10:20
Corretto dettaglio sui Segnalibri in places.sqlite (https://twitter.com/Gioxx/status/750243831132585985)
Condividi l'articolo con i tuoi contatti: