I migliori client Facebook alternativi | Recap

Nei precedenti  articoli di questa rubrica abbiamo esaminato alcuni dei client Facebook reperibili sul Play Store. Della lista stilata inizialmente ho deciso di non recensirne alcuni dato che per prestazioni e funzionalità non apportavano nessun miglioramento visibile oppure erano del tutto simili ad altri già esaminati. Per evitarvi diverse ripetizioni ho pensato fosse più utile raccontarvi la mia esperienza e quale client ho deciso di utilizzare. Avendo provato una decina di client diversi non è stato facile organizzarsi soprattutto per capire quelle che erano le differenze uno con l'altro, quindi inizialmente li ho installati tutti e provati in contemporanea. Dopo di che li ho analizzati più approfonditamente uno alla volta soprattutto per determinare al meglio consumi e prestazioni. Ma ammetto che già da subito mi ero fatto un'idea abbastanza precisa su quali fossero i client degni di nota. Ultimamente ho limitato la scelta a due Phoenix e Friendly. Li ho provati entrambi a lungo, sia sul mio telefono principale (LG G Flex 2), che sul vecchio Samsung S2 Plus con custom rom basata su Android 7.1.2 Nougat. A livello di prestazioni e consumo di batteria entrambi mi hanno soddisfatto anche se sul G Flex 2 non notavo differenze tra i due sul S2 Friendly mi è sembrato più fluido e scattante. Parlando della funzione di ricerca è decisamente meglio implementata in Friendly sia graficamente che per l'immediatezza con cui ci vengono proposti i risultati. Per quanto riguarda gli altri punti che sono stati approfonditi nei relativo articolo non ho trovato grandi differenze. Entrambe sono due ottime applicazioni che hanno molti punti di forza in comune ed è stato difficile scegliere ma alla fine ho optato per Friendly.

Magisk 14, il modding "OTA-friendly" per tutti

15 Ottobre 2017. È questa la data di una nuova importante rivoluzione nel mondo del modding di Android. Tre settimane fa infatti lo sviluppatore topjohnwu ha rilasciato un nuovo aggiornamento di Magisk, raggiungendo la versione 14.Tra le tante novità introdotte, riportate nel changelog a fondo pagina, la più interessante sta nel nuovo metodo di installazione della mod.A fianco a quello classico infatti, che prevede l'utilizzo di una custom recovery come la TWRP per il flash dello zip di Magisk, è stata introdotta la possibilità di generare una boot.img modificata per poi flasharla in qualsiasi modo, potenzialmente senza passare dalla recovery. Questa modalità infatti permette, dando in pasto a Magisk Manager la boot.img originale del sistema del dispositivo, di modificare quest'ultima includendo i file necessari per il funzionamento di Magisk. Il passo successivo sarà quello poi di flashare tale file sul dispositivo, cosa che potrà essere effettuata direttamente dalla modalità fasboot o tramite ODIN per i dispositivi Samsung. Ricapitolando, i passi necessari saranno: Procurarsi l'immagine di boot del proprio sistema (presente nello zip della ROM o dell'aggiornamento ufficiale) e copiarla nel dispositivo Da Magisk Manager premere Installa > Patch Boot Image File e selezionare la boot.img appena scaricata Attendere la fine del procedimento di patching Copiare la nuova boot image sul PC Riavviare il dispositivo in modalità bootloader (collegare il telefono al PC e digitare il comando adb reboot bootloader [1]) Flashare la nuova boot image con il comando fastboot flash boot patched_boot.img [1] Riavviare il dispositivo con fastboot reboot Il risultato sarà quello di aver installato Magisk senza toccare la recovery stock del proprio dispositivo, con la conseguente possibilità di ricevere gli aggiornamenti OTA [2], nonchè di rootare e moddare qualsiasi dispositivo, anche quelli per cui non esiste una custom recovery. Degna di nota è infine la Invincible Mode introdotta con la versione 14.3, l'ultimo di una serie di fix rilasciati in queste tre settimane, che garantisce che il demone di Magisk sia sempre funzionante in background (anche nel caso in cui venga interrotto in modo forzato), così da evitare casuali perdite dei permessi di root o il non funzionamento di Magisk Hide, con conseguente esito negativo del SafetyNet Check. Per concludere vi riporto il changelog ufficiale delle due versioni trattate: • v14.3 (1437)- [MagiskBoot] Fix Pixel C installtion- [MagiskBoot] Handle special lz4_legacy format properly, should fix all LG devices- [Daemon] New universal logcat monitor is added, support plug-and-play to worker threads- [Daemon] Invincible mode: daemon will be restarted by init, everything should seamlessly through daemon restarts- [Daemon] Add new restorecon action, will go through and fix all Magisk files with selinux unlabled to system_file context- [Daemon] Add brute-force image resizing mode, should prevent the notorious Samsung crappy resize2fs from affecting the result- [resetprop] Add new "-p" flag, used to toggle whether alter/access the actual persist storage for persist props• v14.0- [script] Simplify installation scripts- [script] Fix a bug causing backing up and restoring stock boot images failure- [script] Installation and uninstallation will migrate old or broken stock boot image backups to proper format- [script] Fix an issue with selabel setting in util_functions on Lollipop- [rc script] Enable logd in post-fs to start logging as early as possible- [MagiskHide] magisk.img mounted is no longer a requirementDevices with issues mounting magisk.img can now run in proper core-only mode- [MagiskBoot] Add native function to extract stock SHA1 from ramdisk- [b64xz] New tool to extract compressed and encoded binary dumps in shell script- [busybox] Add busybox to Magisk source, and embed multi-arch busybox binary into update-binary shell script- [busybox] Busybox is added into PATH for all boot scripts (post-fs-data.d, service.d, and all module scripts)- [MagiskSU] Fully fix multiuser issues- [Magic Mount] Fix a typo in cloning attributes- [Daemon] Fix the daemon crashing when boot scripts opens a subshell- [Daemon] Adjustments to prevent stock Samsung kernel restrictions on exec system calls for binaries started from /data- [Daemon] Workaround on Samsung device with weird fork behaviors [1] Per effettuare questi passaggi sul PC devono essere installati ADB e FASTBOOT ed il Bootloader del dispositivo deve essere sbloccato. [2] Per installare gli aggiornamenti OTA tutte le partizioni di sistema devono risultare integre e non modificate. Pertanto una modifica in /system o in /boot non permette l'installazione dell'aggiornamento ufficiale. Sebbene Magisk permetta di non alterare la partizione /system, si installa in quella di boot. Per poter installare l'aggiornamento sarà quindi necessario rimuovere temporaneamente Magisk attraverso la voce Disinstalla dall'applicazione Magisk Manager seguendo le istruzioni ufficiali riportate qui.

HTTPS, cos'è e come funziona

L'ultimo articolo riguardante la sicurezza sul web risale a qualche mese fa ed abbiamo deciso di riprendere l'argomento per parlarvi di HTTPS, che da qualche giorno è stato abilitato anche qua su L'angolo nerd. Per molti di voi potrebbe suonare familiare, sicuramente vi sarà già capitato di leggerlo sulla barra degli indirizzi del browser quando navigate su siti come Facebook, Google, Twitter o YouTube, accompagnato da un piccolo lucchetto chiuso. Ma cos'è questo HTTPS? HTTPS sta per HyperText Transfer Protocol over Secure Socket Layer e si tratta di un protocollo per l'invio di informazioni attraverso la rete, proprio come HTTP, ma più sicuro. Giusto per rifilarvi una carrellata di informazioni nerd, il protocollo HTTPS utilizza la porta 443 al posto della usuale porta 80 di HTTP ed un sistema basato su SSL/TLS per cifrare le informazioni scambiate tra il client (voi) ed il server (L'angolo nerd, ad esempio). In particolare, SSL (Secure Sockets Layer) e TLS (Transmission Layer Security) sono altri due protocolli, che vengono utilizzati per garantire la cifratura dei pacchetti inviati tramite rete Internet. Ok, tutto molto bello, ma perchè usare HTTPS?L'utilizzo del protocollo HTTPS garantisce una maggiore sicurezza permettendo lo scambio di dati cifrati tra client e server, evitando quindi attacchi del tipo man-in-the-middle o eavesdropping, mediante il quale l'attaccante, che si trova "a metà" tra voi e il server, potrebbe intercettare le informazioni inviate.Più precisamente, HTTPS NON blocca questi tipi di attacchi, semplicemente li rende inutili. Attraverso il protocollo HTTP standard infatti i dati vengono passati in plain text, ossia non cifrati, permettendo quindi al malintenzionato di scovare facilmente ad esempio il vostro username e la vostra password. Questi dati possono essere intercettati comunque anche se inviati tramite HTTPS, ma risulteranno cifrati, di conseguenza illeggibili. Come funziona HTTPS?HTTPS è basato sul sistema delle chiavi pubbliche e private (trattato nell'articolo sulla crittografia). L'amministratore di un server Web che vuole adottare questa protezione per la connessione dall'esterno al suo server deve prima creare un certificato a chiave pubblica che dovrà poi essere firmato da un'Autorità di Certificazione (CA), un ente pubblico o privato abilitato a rilasciare certificati digitali conformi agli standard internazionali.Nel caso in cui il certificato creato per un server Web non fosse stato firmato il browser ci avviserà che il sito a cui vorremmo connetterci non è sicuro. Ma cerchiamo di capire meglio come funziona questo sistema delle chiavi pubbliche e private. Queste due chiavi sono legate da un calcolo matematico, tipicamente il prodotto di due numeri primi molto (molto molto) grandi, in modo che sia impossibile risalire a quella privata disponendo solo di quella pubblica. Per mandare un messaggio al server basterà cifrarlo utilizzando la sua chiave pubblica, così che solo il server stesso, attraverso la sua chiave privata potrà decifrarlo. Dopo aver messo a punto i dettagli tecnici da utilizzare per il trasferimento, come ad esempio la versione degli algoritmi di protocollo o di cifratura, il browser procederà quindi alla cifratura di una chiave generata in loco con la chiave pubblica del server, per poi connettersi con questo e inviare tale chiave. Terminato questo passaggio la connessione tra il client e il server sarà sicura e procederà con la stessa chiave, che verrà utilizzata per cifrare e decifrare il flusso dei dati. In conclusione è interessante dare uno sguardo alle debolezze e alle limitazioni di questo tipo di comunicazione.Innanzitutto, se un utente malintenzionato rubasse il certificato con la chiave privata di un server che usa HTTPS, sarebbe possibile per lui creare e firmare falsi certificati per qualsiasi dominio a cui far connettere gli utenti senza che loro se ne accorgano. Inoltre, con l'implementazione di HTTPS su un server Web, verranno inviati più dati rispetto che con una normale connessione HTTP. Ciò comporta quindi un volume di traffico più alto, con una conseguente velocità di navigazione ridotta. Ma allora perché non usare il protocollo HTTPS solo sulla pagina di login? Tutti avrete sentito parlare dei Cookie, che essenzialmente sono righe di testo utilizzate per l'autenticazione automatica, quel meccanismo che permette ad esempio di non dover inserire username e password ogni volta che si accede a Facebook o Google. Username e password sarebbero quindi al sicuro perchè cifrati, ma che dire di questi cookie? Questi invece rimarrebbero in chiaro, senza alcun tipo di cifratura, il che renderebbe inutile cifrare i dati al momento del login. Per questo è necessario che la connessione rimanga cifrata per tutta la sua durata, dall'inizio alla fine.

JSE Coin, l'alternativa a Google AdSense

Google AdSense è probabilmente il servizio di remunerazione più noto nell'ambito dell'online publishing. Permette infatti di generare banner pubblicitari da mostrare sul proprio sito, in cambio di piccoli compensi derivati da visualizzazioni e click dei banner stessi. L'angolo nerd adotta questo servizio da diversi mesi, ma si è rivelato essere molto meno profittevole delle aspettative, portando introiti decisamente inferiori rispetto ai costi di mantenimento del sito stesso. Insomma, a meno di non avere almeno più di visitatori al giorno, AdSense non risulta conveniente, soprattutto se si considerano i rallentamenti nella navigazione dovuti al caricamento dei banner pubblicitari offerti da Google. Ma potrebbe esserci una soluzione, un'alternativa ad AdSense e altri circuiti pubblicitari che soffrono delle stesse problematiche, in grado di generare dei profitti senza compromettere l'esperienza utente. JSE Coin è una criptovaluta nata proprio per i webmaster ed è scritta totalmente in JavaScript per permetterne la rapida integrazione con tutti i siti web. L'idea è infatti quella di far eseguire i processi di hashing ai PC dei visitatori durante la loro permanenza sul sito web attraverso uno script caricato dal browser, tutto questo sempre nel rispetto dell'utente. Il mining infatti viene effettuato utilizzando pochissime risorse, tanto da rendere il processo impercettibile in termini di rallentamenti e lag [1]. Inoltre lo script fornisce un banner di notifica che mette a conoscenza l'utente riguardo all'utilizzo di questa tecnologia, permettendogli di disabilitarla (per maggiori informazioni a riguardo vi rimando alla pagina sulla privacy del sito ufficiale). Ma torniamo un attimo ai JSE Coin... quanto valgono? Attualmente, nulla. Più precisamente si tratta di una nuova criptovaluta, lanciata pubblicamente due mesi fa e non ancora quotata in borsa, pertanto le è stato assegnato un valore simbolico di 1$ e, ora come ora, non può nè essere salvata in un portafoglio virtuale, nè scambiata con altre valute, quali possono essere i Bitcoin o i Dollari. L'ingresso sul mercato dei JSE Coin è previsto per metà 2018 in occasione di una ICO (Initial Coin Offering). Attualmente stiamo testando questa nuova tecnologia ed è possibile verificare il corretto funzionamento dello script dalla console del browser, raggiungibile con Ctrl + Shift + J su Chrome e con Ctrl + Shift + K su Firefox (o, in ogni caso con tasto destro > analizza elemento > scheda "Console"). In ogni caso non esitate a contattarci nel caso in cui notiate rallentamenti, lag o impuntamenti del browser durante la navigazione. Per qualsiasi altra informazione a riguardo vi rimando al sito ufficiale di JSE Coin. [1] Un punto a favore di JSE è che, a differenza di altri script miner come il famoso CoinHive, non utilizza il 100% della CPU del computer, ma solo una minima parte. In questo modo l'esperienza utente non viene compromessa, risultando quasi invisibile agli occhi del lettore.

I Bitcoin spiegati a mio padre - la crittografia

Nello scorso articolo abbiamo parlato dell'aspetto economico e della definizione dei Bitcoin in quanto moneta virtuale. Oggi invece andremo ad analizzarne l'aspetto crittografico. L’uso della crittografia risulta essere di importanza cruciale nel sistema Bitcoin; essa è usata per celare l’identità degli utenti della rete grazie alle funzioni Hash, per garantire che il denaro di un portafoglio sia speso solo dal legittimo proprietario, grazie ad uno schema di firma digitale chiamato Algoritmo di Firma Digitale su Curve Ellittiche (ECDSA), o impedire l'alterazione della Block Chain, cioè il registro generale di tutti le transazioni economiche effettuate. Funzioni crittografiche Hash Una funzione crittografica Hash è una funzione H che, dato in input una stringa m di lunghezza arbitraria (potenzialmente infinita), restituisce in output un messaggio H(m) di lunghezza predefinita chiamato digest. La lunghezza del digest è definita dall’algoritmo Hash usato, per esempio, nel sistema Bitcoin vengono utilizzate due funzioni, SHA256 e RIPEMD160 che, rispettivamente, restituiscono un output di 256 bit e 160 bit. Di seguito un esempio dell’output delle due funzioni in formato esadecimale. Ricordiamo che un carattere esadecimale è grande 4 bit, quindi le stringhe in output saranno lunghe rispettivamente 64 e 40 caratteri SHA256(‘Bitcoin’) = B4056DF6691F8DC72E56302DDAD345D65FEAD3EAD9299609A826E2344EB63AA4RIPEMD160(‘Bitcoin’) = 4C9F77AB9E5EEF487C2C0AE07029E79B2CA11A68 Proprietà le funzioni crittografiche Hash: Dato un messaggio m, deve essere impossibile risalire al messaggio originario m dall’output di H(m). Inoltre, deve essere facile e veloce per un calcolatore calcolare l’Hash del messaggio. Dato un messaggio Y deve essere computazionalmente impossibile[ 1 ] trovare un messaggio X tale che H(X) = Y. Proviamo a spiegarlo meglio: ipotizziamo ci sia un messaggio M, il cui Hash sia Y e quindi H(M)=Y. Quello che sottolinea il punto 2 è che deve essere difficile trovare un secondo messaggio X il cui Hash sia uguale a Y. Deve essere computazionalmente impossibile trovare due messaggi m1 e m2 diversi fra loro con H(m1) = H(m2). Dato che il digest ha una lunghezza finita, ci si aspetta che messaggi diversi possano avere Hash uguali. Quello che evidenzia questa proprietà, è che deve essere difficile trovare questi due messaggi m1 e m2, ovviamente più è grande l’output di un Hash, più è difficile che ciò si verifichi.  La differenza dal punto 2 sta nel fatto che in questo caso i due messaggi sono stati scelti da noi. Questo implica che se riuscissi a "violare" questa proprietà, potrei per esempio spacciarmi per un altro utente e usare il suo denaro. Vediamo ora un altro esempio: SHA256(’Bitcoin’) = B4056DF6691F8DC72E56302DDAD345D65FEAD3EAD9299609A826E2344EB63AA4SHA256(’bitcoin’) = 6b88c087247aa2f07ee1c5956b8e1a9f4c7f892a70e324f1bb3d161e05ca107b Come si può notare, una minima variazione nel messaggio iniziale produce un cambiamento radicale nell’Hash ottenuto in output. Perchè questo esempio? Le funzioni Hash vengono usate anche per verificare la correttezza di un messaggio. Infatti inserendo in input la medesima stringa, si avrà sempre il medesimo output. Come riportato dalla guida di Ubuntu, Quando si effettua il download di Ubuntu da internet, c'è la possibilità che il file non venga scaricato nel modo corretto e presenti degli errori. Questi errori possono compromettere la stabilità e/o il funzionamento di Ubuntu. Il programma md5sum è progettato per verificare l'integrità e l'autenticità dei dati usando l'hash crittografica a 128 bit MD5. Infatti, una volta scaricata la iso e il file MD5SUMS contenente l'Hash ufficiale, basterà ricalcolare l'Hash e confrontarlo. Digitando nel terminale il comando  md5sum -c MD5SUMS | grep ubuntu-14.04-desktop-amd64.iso, se non ci sono errori verrà restituito il messaggio: ubuntu-14.04-desktop-amd64.iso: OK Quando un utente effettua un pagamento, viene creata una transazione nel sistema dei Bitcoin. Data l’assenza di un ente centrale, come una banca, a fare da garante, la transazione deve essere verificata sei volte, cioè bisogna verificare che il mittente abbia effettivamente quella somma di denaro. La verifica avviene aggiungendo un nuovo blocco nella Block Chain, il quale conterrà la firma digitale del Hash della transazione precedente. In questo modo chi riceve il pagamento può controllare i diversi passaggi di proprietà della moneta trasferita verificando le firme presenti in ogni transazione. La modifica di una transazione non è quindi possibile poichè gli Hash non corrisponderebbero più. Crittografia asimmetrica La crittografia asimmetrica, conosciuta anche come crittografia a chiave pubblica e privata, è un tipo di crittografia dove ad ogni attore coinvolto nella comunicazione è associata una coppia di chiavi: una chiave pubblica, che può essere diffusa pubblicamente, ed una privata, che deve essere tenuta assolutamente nascosta. La caratteristica principale è che solo ciò che viene cifrato con la chiave pubblica può essere decifrato con la chiave privata associata, e viceversa. Ipotizziamo che Alice voglia mandare un messaggio a Bob. Lei userà la chiave pubblica di Bob Kpub, e genererà il messaggio cifrato. Quando Bob riceverà il messaggio cifrato, userà la sua chiave privata Kpriv per scoprire il contenuto del messaggio. Se C è quindi il messaggio cifrato, ed M il messaggio originale, risulta: C = encrypt(M, Kpub)M = decrypt(C, Kpriv) Firma digitale Con Firma Digitale si intende un mezzo che, grazie alla crittografia asimmetrica, consente di dimostrare l’autenticità di un messaggio. Come una firma su carta, una firma digitale per essere tale deve soddisfare le seguenti caratteristiche: Autenticità: il destinatario di un messaggio firmato può verificare che il messaggio non sia stato inviato da un’altra persona. Integrità: il messaggio non è stato manomesso. Non ripudiabilità: una volta inviato il messaggio, non si può negare di averlo fatto. Per quanto riguarda il sistema Bitcoin, per evitare che durante una transazione si subisca una frode viene eseguito questo algoritmo: Per inviare un messaggio firmato M: Si esegue l’Hash del messaggio: H = SHA256(M) Si cifra H con la chiave privata, per ottenere la firma: S = encrypt(H, Kpriv) Si invia la firma S insieme al messaggio M. Per verificare che la firma S sia valida per il messaggio M: Si esegue l’Hash del messaggio M: H = SHA256(M) Si decifra S con la chiave pubblica: H’ = decrypt(S, Kpub) Si verifica che H = H’. Se risultano uguali la firma è valida. Attacco a collisione Un attacco a collisione è un tipo di attacco in cui si cercano due messaggi in input, i quali producono lo stesso Hash in output. Come già sottolineato, è possibile che questo evento si verifichi, data la lunghezza finita dell'output delle funzioni Hash. Quando ciò si verifica, si dice che si ha una collisione. Quindi se un attaccante riuscisse a generare volutamente un indirizzo uguale a quello di un altro utente, l'attaccante potrebbe spendere il denaro dell'utente col medesimo indirizzo. Tuttavia ciò risulta essere computazionalmente improbabile. Infatti, per creare una collisione, significherebbe calcolare in media, 2^(160/2) valori Hash (ipotizzando un Hash di 160bit). Ad oggi, per calcolare tutti i possibili valori, si impiegherebbe un tempo troppo lungo (migliaia di anni). Lo scopo di questo articolo è stato quello di darvi alcune nozioni base che vi permetteranno più avanti di capire le fondamenta su cui sono stati costruiti i Bitcoin. La Crittografia è un mondo assai ampio e complesso, il quale non può essere riassunto in così poche righe. [1] Una serie di operazioni vengono definite computazionalmente impossibili o intrattabili quando per eseguirle è necessario un tempo lunghissimo (centinaia di anni) utilizzando il super computer più veloce attualmente esistente. Fonte: Introduction to Cryptography with Coding Theory

[TaskerTime] Musica nelle tue cuffie!

Eccoci ad un altro capitolo della nostra rubrica TaskerTime. Oggi vediamo come, inserendo le cuffie nello smartphone, avere l'immediato avvio della musica. Per farlo basteranno pochi passaggi: aggiungiamo lo Stato - Cuffie Collegate - Qualunque. Come nuova attività in entrata associata allo Stato, impostiamo Volume Media - Livello 9 per avere un volume iniziale medio-alto e Controllo Media - Play [Simulazione] selezionando come App l'applicazione da noi scelta. Nel mio caso, ho scelto il music player predefinito. Come attività in uscita Volume Media - Livello 0, Controllo Media - Stop e Kill App - Musica Se riceviamo un messaggio audio o guardiamo un video e vogliamo ascoltarlo in cuffia, per quanto detto sopra, partirà automaticamente la musica, portandoci ad odiare il nostro amato plugin. Per questo motivo dobbiamo effettuare qualche cambiamento alla configurazione precedente. Creiamo una variabile %Social settata a 0 e aggiungiamo come Applicazione tutte quelle apps per le quali non vogliamo che parta la musica quando sono in primo piano. Come attività in ingresso al task Applicazione appena creato,  impostiamo Imposta %Social a 1, e come attività in uscita Imposta %Social a 0. La stessa configurazione dobbiamo impostarla per il nuovo stato Chiama - Tutti, in modo da non far partire la musica se riceviamo o effettuiamo una chiamata. Ora non ci resta che modificare l'attività in entrata di Cuffie Collegate un If, che eseguirà Controllo Media - Play solo se la variabile %Social è uguale a 0.