Good news, Apple and Google are partnering to implement system-level APIs for a privacy friendly contact tracing done via bluetooth (which, as we were discussing the other day, seems the most sensible approach):

Apple and Google will work to enable a broader Bluetooth-based contact tracing platform by building this functionality into the underlying platforms. This is a more robust solution than an API and would allow more individuals to participate, if they choose to opt in, as well as enable interaction with a broader ecosystem of apps and government health authorities. Privacy, transparency, and consent are of utmost importance in this effort, and we look forward to building this functionality in consultation with interested stakeholders.

From a draft of the spec (up here):

The Contact Tracing Bluetooth Specification does not require the user’s location; any use of location is completely optional to the schema. In any case, the user must provide their explicit consent in order for their location to be optionally used.

The Next Web:

Internet Service Providers (ISPs) are probably soon going to dictate what traffic can or cannot arrive at people’s end devices. GOOG-FB-AMZN traffic would be the most common, due to their popularity among internet users. Because of this market demand, ISPs will likely provide cheap plans with access to GOOG-FB-AMZN, while offering more expensive plans with full internet access — and it’s already a reality in countries like Portugal.

This would expand even more the dominance the three tech giants already enjoy. There would be no more economical incentive for smaller businesses to have independent websites, and a gradual migration towards Facebook Pages would make more sense. Smaller e-commerce sites would be bought by AMZN or go bankrupt. Because most internet users couldn’t open all the sites, GOOG would have little incentive to be a mere bridge between people and sites. […]

The common pattern among these three internet giants is to grow beyond browsers, creating new virtual contexts where data is created and shared. The Web may die like most other technologies do, simply by becoming less attractive than newer technologies. And like most obsolete technologies, they don’t suddenly disappear, neither do they disappear completely.

Secondo Thom Holwerda, che scrive su OSNews, nei prossimi anni Android subirà una trasformazione radicale volta a lasciarsi alle spalle alcuni dei problemi fondamentali che Google negli anni non è riuscita a risolvere, ma che porterà anche all’abbandono di Linux.

Da dove viene il sospetto? Molte risorse e diversi fra i principali sviluppatori di Google stanno lavorando su Fuchsia — un sistema operativo sperimentale, dice Google —, invece che su Android:

Android in its current form suffers from several key architectural problems – it’s not nearly as resource-efficient as, say, iOS, has consistent update problems, and despite hefty hardware, still suffers from the occasional performance problems, among other things – that Google clearly hasn’t been able to solve. It feels like Android is in limbo, waiting for something, as if Google is working on something else that will eventually succeed Android.

Is that something Fuchsia? Is Project Treble part of the plan, to make it easier for Google to eventually replace Android’s Linux base with something else? If Android as it exists today was salvageable, why are some of the world’s greatest operating systems engineers employed by Google not working on Android, but on Fuchsia? If Fuchsia is just a research operating system, why did its developers recently add actual wallpapers to the repository? Why does every design choice for Fuchsia seem specifically designed for and targeted at solving Android’s core problems?

Nick Heer:

Consider this: Google owns the most popular search engine and the biggest video hosting platform in most countries, operates one of the most-used email services on Earth, has the greatest market share of any mobile operating system, makes the most popular web browser in many countries, serves the majority of the targeted advertising on the web, provides the most popular analytics software for websites, and is attempting to become a major internet service provider. And, to cap it all off, they’re subtly replacing HTML with their own version, and it requires a Google-hosted JavaScript file to correctly display.

Google AMP è una pessima idea che doveva morire sul nascere:

• Google infila il suo dominio davanti all’URL di ogni pagina web che ne fa uso
• Visivamente, rende identica una notizia proveniente dal The Guardian a una proveniente da Breitbart
• Una volta implementato è difficile da togliere
• Le pagine web si possono fare veloci senza AMP; non c’è nessuna ragione per cui AMP debba esistere. A parte che torna utile a Google
• È Google che deve adattarsi al web, non le pagine web che devono adattarsi alle necessità di Google

Big Medium spiega come Google potrebbe risolvere il problema delle risposte sbagliate. Il problema è, principalmente, un problema di design: c’è molto che Google potrebbe fare per presentare le risposte in maniera differente, invece che come la verità assoluta.

Google gives only the shallowest context for its featured snippets. Sure, the snippets are always sourced; they plainly link to the page where the answer was extracted. But there’s no sense of what that source is. Is it a Wikipedia-style reference site? A mainstream news site? A partisan propaganda site? Or perhaps a blend of each? There’s no indication unless you visit the page and establish the identity and trustworthiness of the source yourself. […]

People don’t click the source links, and that’s by design. Google is explicitly trying to save you the trouble of visiting the source site. The whole idea of the featured snippet is to carve out the presumed answer from its context. Why be a middleman when you can deliver the answer directly?

In riferimento al post precedente, The Outline racconta la storia di Shiva Ayyadurai, un tizio che dice di avere inventato l’email. Con i vari domini (tutti relativi alla posta elettronica) registrati a suo nome è riuscito a ingannare Google, che alla domanda ‘Chi ha inventato l’email?‘ un po’ di tempo fa rispondeva Shiva Ayyadurai senza indugio.

Fonte dello snippet? Il sito stesso del tizio, come racconta The Outline:

Here’s what a search for “who invented email” turns up on Google. It’s Shiva Ayyadurai. The source is Shiva Ayyadurai’s website. The snippet isn’t even in full sentences because it’s so stuffed with keywords. The issue with this particular featured snippet is bigger than one wrong answer. It’s that Google got roped into a disinformation campaign waged by Ayyadurai.

Da un paio d’anni Google ha iniziato a dare risposte: a selezionare, fra le fonti e i risultati di una ricerca, una singola risposta da evidenziare in un riquadro in cima alla lista dei risultati. Google promuove questi risultati dandogli un maggiore peso visivo e includendo il loro contenuto direttamente nella pagina dei risultati — evitando così all’utente di dover visitare un altro sito per leggerli. Li chiama featured snippets:

Quando un utente pone una domanda, la risposta restituita potrebbe essere mostrata in un riquadro speciale di snippet in primo piano nella parte superiore della pagina dei risultati di ricerca. Questo riquadro di snippet in primo piano include un riepilogo della risposta estratto da una pagina web, insieme a un link alla pagina, il relativo titolo e l’URL.

L’obiettivo è quello di riuscire a rispondere direttamente alle domande dell’utente, invece di essere uno strumento di ricerca per trovare e valutare delle possibili risposte. Stando ai dati raccolti da Google agli utenti queste risposte senza sforzo, immediate, piacciono — perché possono trovare quello che cercano senza dover visitare un altro sito o un’altra app. Funzionano molto dai dispositivi mobili — perché siamo più di fretta — ma soprattutto sono un vantaggio competitivo per quanto riguarda gli assistenti vocali: una lista di risultati non funziona su smartwatch e assistenti come Google Home e né Siri né Echo sono al momento in grado di fornire risposte dirette estrapolate da pagine web.

Il problema è che, come sottolinea un post di The Outline, queste risposte a volte sono assurde, sbagliate, aiutano a diffondere teorie cospirazioniste; sono insomma inaffidabili. Google risponde Obama alla domanda ‘chi è il re degli Stati Uniti?’, pensa che lo stesso stia pianificando un colpo di stato, e spiega che tutte le donne sono prostitute se gli si chiede ‘perché le donne sono cattive?’. Un algoritmo, basato su popolarità di un risultato, pagerank e altri oscuri criteri, promuove un risultato a risposta in automatico. Google ha la capacità di intervenire manualmente per modificare le risposte di certe ricerche, e spesso lo fa, ma è probabile che passi del tempo prima che si renda conto sia necessario intervenire — e in quel tempo molte persone leggano la risposta fasulla:

In theory, featured snippets will always temporarily turn up some bad answers, but the net effect would be better answers. “It’ll never be fully baked, because Google can’t tell if something is truly a fact or not,” said Danny Sullivan of Search Engine Land. “It depends on what people post on the web. And it can use all its machine learning and algorithms to make the best guess, but sometimes a guess is wrong. And when a guess is wrong, it can be spectacularly terrible.”

Tutto ciò è un problema perché, stando a un recente sondaggio, il 63% delle persone si fida di Google. Queste risposte sono decontestualizzate: l’utente non visita il sito originario, non nota il layout, il contenuto o gli autori (tutti indizi che aiutano a valutare la veridicità di una fonte), ma le legge attraverso l’interfaccia pulita di Google, e potrebbe così essere portato a pensare che queste risposte vengano direttamente da Google (il problema è peggiore con gli assistenti vocali).

Retroscena di Ara, lo smartphone modulare e scomponibile nato come meme da un video caricato su YouTube, implementato da Motorola/Google, poi abbandonato senza conclusione poco dopo la nascita di Alphabet:

“One of the modules that we were working on was basically like a tiny aquarium for your phone,” said the source. “It was a little tiny biome that would go inside of a module and it would have a microscope on the bottom part, and it would have live tardigrades and algae — some people call them water bears. They are the tiniest living organism. We had this idea to build a tardigrade module and we’d build a microscope with it. So you’d have this app on your phone and you could essentially look at the tardigrades up close and watch them floating around.” Brooklyn-based art, design, and technology agency Midnight Commercial conceived the idea, and was commissioned by Google to build it, demonstrating the depth of what developers could create.

Un esperimento di Google in grado di riconoscere quello che disegnate. Avete venti secondi di tempo per disegnare un concetto, e Google in quegli stessi venti secondi dovrebbe riuscire a identificare quel che state disegnando.

Ci ha preso quasi sempre con i miei decisamente orribili e confusi schizzi. Per intenderci: l’umano che siede di fronte a me ci ha preso meno di Google su quel che rappresentassero.

(Altri esperimenti inquietanti qui)

Quando nel 2007 Google acquistò il network pubblicitario DoubleClick, promise che i dati raccolti tramite l’ad tracking non sarebbero stati mischiati con gli altri dati che Google già ha sui propri utenti, grazie ai servizi che offre. In altre parole, Google promise che non avrebbe dato un nome e un cognome ai dati che avrebbe raccolto online: ai siti che visitiamo, o a come ci comportiamo e dove clicchiamo su questi siti.

Nel corso dell’estate, questa promessa è sparita dalla privacy policy:

But this summer, Google quietly erased that last privacy line in the sand – literally crossing out the lines in its privacy policy that promised to keep the two pots of data separate by default. In its place, Google substituted new language that says browsing habits “may be” combined with what the company learns from the use Gmail and other tools. […]

The move is a sea change for Google and a further blow to the online ad industry’s longstanding contention that web tracking is mostly anonymous. In recent years, Facebook, offline data brokers and others have increasingly sought to combine their troves of web tracking data with people’s real names. But until this summer, Google held the line.

La conseguenza è che ora, grazie alle pubblicità di DoubleClick sparse in giro per il web, e grazie a Gmail e agli altri servizi che l’azienda offre, Google può fornire pubblicità ancora più mirata e costruire profili dettagliati sui suoi utenti — basati su quello che scriviamo nelle email, sulle ricerche che facciamo e, ora, anche sui siti che visitiamo.

Per qualche ragione, Google insiste nel voler utilizzare Material Design — il linguaggio visivo e guida creata da Google su come realizzare un’UI per Android — anche su iOS. Il risultato è spiacevole: non seguendo le convenzioni di iOS, non utilizzando San Francisco come font, non rispettando lo stile di default dei bottoni e mettendo ombre un po’ ovunque, quando si apre un’app di Google si viene catapultati in un mondo a parte, che stona con il contesto e semplicemente rompe i pattern visivi che gli utenti hanno imparato altrove.

Jason Snell ricorda che anche Microsoft, a un certo punto, ebbe un approccio simile. Word su Macintosh iniziò a funzionare come Word su Windows, a discapito dell’usabilità:

While Microsoft was busy building its Windows empire, from the very beginning it had been a good citizen on the Mac. Word and Excel had been with the Mac since the beginning. Excel was born on the Mac. I would wager that Word and Excel were the two most popular third-party programs on the Mac back in those days.

Then came 1993, and something funny happened: Microsoft released new versions of Microsoft Office for the Mac, all based on the Windows code base. The familiar Mac versions of Microsoft’s apps vanished, replaced by programs that didn’t behave like Mac apps at all. They were very clearly members of the Office for Windows suite, ported over to the Mac.

Why did Microsoft do it? To this day I can’t decide if they were so high on the greatness of Windows that they imagined Mac users would take to the new Office like a glass of ice water in hell, or if they just cared so little for the Mac that it was no longer worth creating apps specifically for the Mac.

Buona idea, mettere una tastiera nell’orologio.

Google ha fatto delle app istantanee, che si possono aprire senza prima doverle scaricare:

Someone sends you a “deep link” from an app—that’s a link that might go all the way to a product or piece of media—and when you tap it, the app just appears on your phone in that exact spot. So it will take you right to, say, a pair of shoes on Zappos. The UI is fully functional, too—its buttons will actually work. And your payment information is even stored inside Google, so you can feasibly buy those shoes without entering your credit card or shipping info.

Serve in quei casi in cui l’applicazione ha un singolo scopo o una singola funzionalità — normalmente, app di questo tipo vengono scaricate per venire utilizzate due o tre volte. Oppure quando un link sul web tenta di aprire una parte di un’app (come nel caso di Medium o YouTube).