Archivi categoria: Google

Arriva Chrome 68 e Aruba regala certificati SSL a tutti

Facebooktwittergoogle_plusredditlinkedin

La nuova versione del browser Google segnalerà come “non sicuri” i siti sprovvisti di certificato per garantire un maggior numero di connessioni sicure. Per il mondo di Internet si avvicina la fatidica “ora X”, il momento, cioè, in cui i browser più diffusi cominceranno a creare veri problemi ai siti Internet che non utilizzano certificati […]

L’articolo Arriva Chrome 68 e Aruba regala certificati SSL a tutti proviene da Securityinfo.it.

Il mondo del cloud ibrido per Acronis

Facebooktwittergoogle_plusredditlinkedin

Grazie alla recente partnership con Google Cloud, Acronis garantisce alle organizzazioni di ogni dimensione di poter fare la scelta adeguata e perfino di personalizzarla. La convenienza del cloud pubblico è evidente a molti: consente infatti di trasformare l’infrastruttura back-end in una soluzione off-site, riducendo gli investimenti destinati alle risorse quali gli oneri finanziari, i requisiti […]

Google diventa Platinum Member della Linux Foundation

Facebooktwittergoogle_plusredditlinkedin

Google, almeno pubblicamente, ha sempre promosso e sostenuto l’ideologia Open Source. Dall’utilizzo di progetti basati su quell’ideale (Linux fra tutti), fino a scrivere e pubblicare loro software che, in alcuni casi, sono stati ampiamente accettati ed integrati in quello che è l’attuale internet; Kubernetes, giusto per fare un esempio tra i più recenti, proviene proprio da Google, cha ha rilasciato il codice di questo tool utilizzato internamente alla comunità, rendendolo di fatto uno dei progetti più “caldi” di questi ultimi anni.

Certo, se andiamo a spulciare bene, Google si tiene ben stretta i propri segreti e, soprattutto quando ci sono in ballo i profitti considerevoli della società, l’open source passa velocemente in secondo piano.

Ma l’ampiezza stessa della società fa si che, se anche qualcosa rimane segreto negli uffici di Menlo Park, i contributi alla community restano così tanti da farle guadagnare il titolo di Platinum Member della Linux Foundation, il livello più alto di membership fornito dalla fondazione (un’altra società ad avere questo livello è, neanche a dirlo, Microsoft).

Con 10000 progetti open source a cui ha contribuito ed il supporto ad alcune delle più ampie community quali Cloud Foundry, Node.js Foundation, Open API Initiative e Cloud Native Computing Foundation (che ha contribuito a fondare grazie proprio a Kubernetes), diciamo che forse un pochino se lo merita questo riconoscimento.

Open source is an essential part of Google’s culture, and we’ve long recognized the potential of open ecosystems to grow quickly, be more resilient and adaptable in the face of change, and create better software. The Linux Foundation is a fixture in the open source community. By working closely with the organization, we can better engage with the community-at-large and continue to build a more inclusive ecosystem where everyone can benefit.

L’open source è una parte essenziale della cultura di Google, e da tanto tempo riconosciamo il potenziale di un ecosistema aperto di crescere rapidamente, essere più resistente ed adattabile al cambiamento, e creare software migliore. La Linux Foundation è un capisaldo nella comunità open source. Lavorando a stretto contatto con l’organizzazione, possiamo interfacciarci meglio con le community nel senso più ampio del termine, e continuare a costruire un ecosistema più inclusivo in cui tutti possano trarre benefici

Questo quanto affermato da Sarah Novotny, responsabile delle strategie open source di Google Cloud, che grazie anche a questo riconoscimento entra a far parte della dirigenza della stessa Linux Foundation.

Che sia un primo passo per un futuro in cui Google effettivamente si sposti completamente sull’open source, o è un ulteriore modo per mostrare una singola sfacettatura -quella più user-friendly- della società?

Bank Leumi: la Google del mercato finanziario

Facebooktwittergoogle_plusredditlinkedin

Le banche che vogliono avere successo nell’era digitale devono rimuovere gli ostacoli per i clienti e cambiare il proprio linguaggio, come sostiene Ilan Buganim, Chief Technology Officer e Chief Data Officer di Bank Leumi, parte del Leumi Group, il più grande Istituto bancario in Israele.
In un’intervista con VMware, IIan ha sottolineato come le banche stiano cambiando e cosa questo implichi sia per i clienti sia per gli Istituti cui essi si affidano. “Per dimostrare la propria differenziazione, le banche devono essere molto più proattive. Fino a oggi, quando un cliente desiderava parlare con una banca, doveva comprendere come quella lavorasse e i canali di comunicazione a disposizione. In futuro, dovrà essere la banca a imparare cosa rende i servizi bancari più accessibili per il cliente, dove egli risiede e se è più semplice per lui comunicare via WhatsApp o Messenger.”

Questo significa che, mentre i servizi bancari diventeranno sempre più semplici per i clienti, “renderanno la vita delle banche molto più complicata, poiché ogni istituto bancario dovrà essere in grado di costruire un differenziatore digitale, e questo è realizzabile esclusivamente tramite l’innovazione.”

I consigli di Buganim non si basano solo su principi teorici, ma anche su evidenze e sull’esperienza reale. Nel 2017 Bank Leumi ha lanciato Pepper, un servizio di mobile banking innovativo. “Il nostro intento era di posizionarci come la Google o la Facebook del settore finanziario. Per riuscirci, dovevamo creare una mobile bank che si rivolgesse ai millennial, offrendo ai clienti più trasparenza e parlando loro in un linguaggio più comprensibile.”

Pepper è un’esperienza di banking interamente mobile. Il processo di aprire un account richiede solo pochi minuti, dopodiché i clienti possono accedere alle funzioni del conto corrente e a una linea di credito attiva direttamente dal proprio telefono. Basato su una tecnologia unica che può aiutare i clienti a gestire al meglio le proprie finanze, il servizio di Pepper impara a conoscere i propri utenti, adatta i contenuti in modo che siano più rilevanti per loro e offre un’esperienza di banking personalizzata.

I risultati parlano da sé. Come afferma Buganim, Pepper ha visto “una crescita molto forte e sostenuta, che ha portato nuovi clienti che sono molto soddisfatti del servizio. Con una personalizzazione sempre maggiore, stiamo offrendo un modo di fare banking totalmente nuovo, dotato di un linguaggio più customer-friendly.”

L’infrastruttura cloud di VMware consente a Pepper di essere molto più flessibile e in grado di implementare rapidamente nuove funzionalità per i clienti. Basandosi sull’esperienza che hanno acquisito dalla realizzazione di Pepper, Bank Leumi e VMware possono ora offrire una piattaforma di digital banking avanzata per le banche, per sostenerle nell’adozione della digitalizzazione. “Con questa piattaforma, pensiamo di poter essere un acceleratore per le banche. Possiamo lavorare in sinergia con loro perché introducano questa piattaforma, adattandola alle loro necessità e mercati.”

In questo video, Buganim e Manasee Dash di VMware discutono nel dettaglio l’impatto che ha avuto Pepper, come la partnership tra Bank Leumi e VMware possa aiutare le banche a entrare nell’era digitale e come le banche debbano adattarsi per offrire un’esperienza senza intoppi per i propri clienti.

Per scoprire di più sulla piattaforma di digital banking avanzato clicca qui.

 

Google e Microsoft scoprono una nuova vulnerabilità nelle CPU e la fix rallenta ulteriormente le macchine

Facebooktwittergoogle_plusredditlinkedin

Brutte notizie per le CPU di tutto il mondo, già flagellate dallo scorso dicembre dal problema Meltdown e Spectre. Brutte, ma come abbiamo sempre detto, in qualche modo attese. È infatti recente la notizia, che riporta The Verge, della scoperta da parte di Google e Microsoft di una nuova falla denominata Speculative Store Bypass che nella sostanza ripercorre i tratti di quella speculative execution causa di tutti i grattacapi che stiamo vivendo in questi mesi, eccola spiegata molto chiaramente in questo video:

La cosa peggiore è che la soluzione di questo problema una volta applicato al firmware delle CPU ne cala le performance tra il 2 e l’8 percento. Non poco, se sommato a quanto già le CPU sono state rallentate dalle precedenti fix per Spectre.

E le grandi aziende cosa fanno nel frattempo? Si va da Microsoft che sta offrendo fino a duecentocinquantamila dollari per la scoperta di bug simili a Meltdown e Spectre fino ad arrivare in qualche modo ad Intel che è al lavoro sulle modifiche alle CPU del futuro, che vedranno la luce alla fine di quest’anno. Il che, se non lo si fosse capito, significa che il tempo delle patch non è affatto finito, tutt’altro: il bello deve ancora venire!

Primi effetti su Wine per Oracle vs Google… E se Microsoft dedicesse qualcosa di simile?

Facebooktwittergoogle_plusredditlinkedin

Solo poco tempo fa, nel caso che vede Google contrapposta ad Oracle, abbiamo dato la notizia della decisione della corte di ritenere le API di Java sotto copyright, e il loro uso (con reimplementazione su altri sistemi) da parte di Google illegittimo; ora i primi effetti – la paura – di quella sentenza si cominciano a vedere.

Domenica 1 aprile (Pasqua), nella newsletter di Wine, è comparso un messaggio:

Does anyone know exactly how much this ruling affects Wine? Can we ask the SFC for a legal opinion?

Qualcuno sa esattamente in che misura questa sentenza impatta Wine? Possiamo interpellare l’SFC [Software Freedom Conservancy] per un parere legale?

La preoccupazione nasce dal fatto che Wine rende trasparenti le chiamate alle API per il programma (pensato in origine per funzionare nativamente sotto Windows) e si teme quindi che Microsoft possa intentare una causa simile a quanto fatto da Oracle contro Google. Con un precedente simile la vittoria sarebbe molto probabile.

Come potete ben capire l’analogia è molto forte, tanto che il comitato di gestione di Wine venerdì ha risposto di essere già in contatto con la Software Freedom Conservancy:

The committee has been in contact with Conservancy about this.

Il comitato ha già preso contatto con la Conservancy a questo riguardo.

La Software Freedom Conservancy è un’organizzazione nata nel 2006, che (come la Free Software Foundation) ha l’obbiettivo di promuovere e difendere l’esistenza di software gratuito, libero e open source (FLOSS – Free, Libre, Open Source Software). Conta ormai più di 40 progetti, compresi Git, BusyBox, Boost, Inkscape, QEMU e – appunto – Wine.

Quindi?

As of now, what we’ve learned is that it’s too early to know the effect the decision will have. It’s important to note that the decision isn’t binding on any other courts in the country, and it could be years for the appeals process to complete.

Per ora, quel che sappiamo è che è troppo presto per sapete che effetto avrà la sentenza. È importante notare che la sentenza non lega alcuna altra corte del Paese, e che potrebbero volerci anni per completare il processo di appello.

Insomma, non è ancora stata detta la parola fine. Al meglio, rimandato di qualche anno. Chissà che per allora Microsoft non abbia deciso di regalare le API di Windows alla comunità Linux, di cui ormai fa parte😉

Google e l’OS color Fuchsia

Facebooktwittergoogle_plusredditlinkedin

Che Google abbia sempre qualche cosa in sviluppo, valutazione o sperimentazione è indubbio. Spesso questi progetti sono anche pubblici, ma senza pubblicità che attiri l’attenzione.

Da un paio d’anni ha in sviluppo Fuchsia, un nuovo sistema operativo costruito in casa fin dal kernel, chiamato Zircon. In questi anni ogni tanto è apparso qualche riferimento, ma è rimasto sconosciuto lo scopo, il perché sviluppare un altro sistema operativo. Lo è tutt’ora, ma adesso abbiamo qualche dettaglio su cosa sia Fuchsia, e in cosa si differenzi da quanto già visto.
Google ha infatti pubblicato la documentazione, chiamata The Book.

Fuchsia is not Linux

Fuchsia non è Linux

Le prime parole del documento (nonché il titolo del primo paragafo) servono ad affermare una cosa non ovvia, di questi tempi: il nuovo sistema operativo non è in alcun modo basato su Linux. Fuchsia ha un kernel suo e programmi suoi, tutto fatto in  casa.
Un sistema operativo è formato da almeno due parti: il kernel, che si occupa di gestire l’hardware, ed i programmi base, che danno istruzioni al kernel. Le varie distribuzioni Linux (di cui così spesso parliamo) sono una combinazione del kernel Linux e dei programmi GNU (tanto che sarebbe corretto riferirsi sempre a sistemi GNU/Linux).
Come visto quando abbiamo parlato di Meltdown, lo spazio di memoria assegnato al kernel è separato da quello dei programmi, ed anche quello che può fare il kernel è diverso: dovendo gestire l’hardware, il kernel può mandare dei comandi ai dispositivi, mentre i programmi devono usare il kernel.

Tutto in userland

Leggendo la documentazione salta all’occhio come molte funzioni, che normalmente vediamo parte del kernel (al massimo come modulo da caricare), in Fuchsia siano processi (chiamati servizi) che girano nello spazio utente.
Per esempio, per accedere ad un file normalmente viene chiamato un programma che individua il file in un filesystem (caricato nel kernel), il quale usa un driver (caricato nel kernel) per leggere i dati memorizzati fisicamente sul disco.
In Fuchsia succede una cosa molto simile, ma non identica: un programma chiede il file ad un filesystem (che è un servizio, ovvero un altro programma), il quale chiede informazioni ad un driver (che è un altro servizio) per dare le istruzioni al kernel che legge fisicamente i dati dal disco; la catena di comunicazioni quindi procede a ritroso: il driver comunica il risultato al filesystem che comunica la disponibilità o meno dei dati al programma richiedente.

Scambio messaggi, non dati

Normalmente filesystem e driver devono essere scritti nello stesso linguaggio del kernel, e ne devono condividere le strutture dati visto che usano direttamente quei dati. Questo porta ad uno svantaggio: ad ogni aggiornamento della struttura dati del kernel, il modulo deve essere ricompilato e/o in parte riscritto, per adeguarsi ai cambiamenti.
In Fuchsia i componenti sono programmi a sé stanti che comunicano tra di loro con un protocollo standard: qualunque programma, scritto con qualsiasi linguaggio, sia in grado di comunicare con quel protocollo (chiamato RemoteIO) può svolgere quel compito. Questo vuol dire anche che l’aggiornamento di uno di questi componenti (kernel, filesystem o driver) non implica l’aggiornamento di tutti, e le modifiche di funzionamento o rappresentazione dei dati interno non coinvolge gli altri componenti.

A chi è destinato tutto questo?

Non ci dilungheremo oltre sulle caratteristiche tecniche, che sono peraltro ben approfondibili grazie proprio al Libro di Google. Aggiungiamo solo che l’architettura sembra studiata per avere nativamente certe caratteristiche:

  • un alto livello di sicurezza: ogni processo è indipendente e potrebbe aver accesso solo allo stretto necessario;
  • multipiattaforma: il (micro)kernel e la modularità dei servizi permetterà di avere solo i componenti necessari su hardware embedded, mentre più generale e completo su altri tipi di hardware; inoltre, grazie al sistema a servizi non si è legati ad un linguaggio specifico;
  • facilità di manutenzione: l’aggiunta, l’aggiornamento o la rimozione di un servizio sono istantanei e indipendenti dagli altri.

Queste caratteristiche fanno pensare ad un uso che spazia dai pc ai telefonini, tanto che qualcuno ha già ipotizzato possa essere il futuro sostituto di Android e ChromeOS.
Noi crediamo sia semplicemente un po’ troppo presto per dirlo: il sistema è ad uno stadio di esercizio di stile, non ancora definibile nemmeno come versione Alpha (in cui le funzionalità base sono state implementate), quindi per poter valutare cosa effettivamente sia e dove potrebbe avere senso usare Fuchsia ci vorranno ancora anni.

In compenso, ci fa molto piacere che esista, e che si stia sviluppando tanto velocemente, un’alternativa. Opensource, naturalmente.

Oracle vs Google: la saga per Android continua

Facebooktwittergoogle_plusredditlinkedin

Quasi due anni fa parlavamo di questa stessa vicenda, che ormai si trascina da otto anni. E, incredibilmente, non è ancora finita.

L’oggetto del dibattito è il sistema Android, scritto (in gran parte) in Java, grazie alla sua particolarità di generare del codice eseguibile da una grande varietà di dispositivi tramite un programma, la Java Virtual Machine, specifico per il dispositivo. Le specifiche del linguaggio sono libere, ma le implementazioni sono molte; quella di riferimento è sotto copyright ed era distribuita – gratuitamente – da SUN. Nel 2010 Oracle compra SUN, con la sua implemetentazione, e da allora reclama un risarcimento danni a Google per aver usato Java senza permesso.

Esponiamo l’ultima puntata della saga, ma più sotto trovate un riassunto.

A maggio del 2016 la giuria aveva decretato che quello di Google era a tutti gli effetti un uso equo (fair use), ovvero un uso senza fine di lucro (dato che Android, in sé, è opensource e distribuito gratuitamente). Ma il giudice, pochi giorni fa, ha deciso che questa decisione era tecnicamente sbagliata: il fatto che fosse “poco” codice non implicava fosse “poco importante” (uno dei possibili requisiti per il fair use), e quindi ha ribaltato la sentenza: Google ha torto e deve pagare i danni ad Oracle. Quanto? Altro processo per definirlo, ma Oracle chiede non meno di  8,8 miliardi di dollari: 3 volte il fatturato di RedHat.

Le armi a disposizione di Google per evitare un tale esborso sono molte poche; la più efficacie, il ricorso alla corte suprema della California, potrebbe essere anche la più spuntata: già nel 2014 ha tentato questa strada, e la corte ha semplicemente declinato la richiesta. Forse, questa volta, dovrò davvero pagare.

In realtà il problema non è solo una questione di soldi tra Google e Oracle, ma rappresenta un precedente pericolo per l’opensource in generale, in quanto le API rappresentano il codice “di contatto” tra un programma e l’altro, create proprio con l’intento di essere riusate e distribuite: il precedente per cui sono coperte da copyright e non possono essere nemmeno re-implementate rappresenta un concreto ostacolo al loro riuso, ed al riuso del codice in generale.

La sentenza cerca di limitare l’effetto a questo caso, ma rimane davvero indubbio che uno sviluppatore, prima di usare codice scritto da altri, ci penserà almeno due volte…

Piccolo riassunto

Il contendere è il sistema Android (e nello specifico gli introiti generati da esso), il celeberrimo – e usatissimo – sistema operativo oramai sinonimo di smartphone – almeno come unica alternativa ad Apple ed al suo iOS.
Android è basato su Java, che di per sé è un linguaggio opensource, ovvero le sue specifiche sono di pubblico dominio, ma l’implementazione di quelle specifiche, ovvero il codice che viene effettivamente eseguito da un computer, può essere messa sotto copyright, come qualsiasi altro software. Nello specifico, in questo caso, si parla delle API, ovvero la parte più superficiale dell’implementazione fatta apposta per interagire con altri programmi – o diventarne parte.

Quando Google iniziò lo sviluppo di Android, alcune di queste interfacce non erano disponibili per il Java usato dai telefonini, e pensò di ricreare (copiare, se volete) quelle usate sui PC, prendendo spunto dall’implementazione che era (ed è) quella di riferimento: quella di Sun – nel frattempo comprata da Oracle. Il tutto, però, senza chiedere esplicitamente il permesso.

Appena acquisita Sun, Oracle intenta la (prima) causa, che genera una vera e propria telenovela:

  • 2010 – Oracle dice che sono stati infranti dei brevetti e che le API sono sotto copyright: perde subito sul brevetto. Google sostiene di rientrare nel caso di fair use.
  • 2012 – Oracle perde anche sul copyright: per il giudice le API e il codice sono cose diverse, e le prime non sono coperte; fa ricorso.
  • 2014 – Oracle vince: all’appello si stabilisce che le API sono sotto copyright. Google sostiene che allora rientra in gioco il fair use: la giuria deve esprimersi.
  • 2016 – (puntata scorsa) La giuria stabilisce che Google rientra nella fair use. Ma manca ancora la sentenza…