Un fastidioso bug visivo sta affliggendo alcuni utenti di OPPO Find X9 Ultra: durante le riprese video, i soggetti bianchi tendono a virare verso tonalità rosa o magenta in modo del tutto inaspettato. Il problema è emerso sui social cinesi durante i giorni festivi ed è ora al centro dell’attenzione, soprattutto in vista del lancio internazionale del dispositivo.

Cosa succede esattamente

Stando alle segnalazioni degli utenti, il fenomeno si manifesta in modo piuttosto evidente: nuvole bianche che appaiono rosa nei filmati, abiti chiari che cambiano colore durante la registrazione, e in generale una dominante cromatica innaturale su elementi che dovrebbero risultare neutri. La causa sembra essere un difetto nel processore di immagini o nell’algoritmo di bilanciamento del bianco applicato ai video.

Un problema che arriva nel momento peggiore

OPPO aveva posizionato il Find X9 Ultra come un riferimento assoluto per la fotografia mobile, con un sistema di ottiche di primissimo livello. La comparsa di un bug così visibile nelle riprese video rischia di offuscare l’immagine del prodotto, soprattutto perché il lancio internazionale — previsto per l’estate — si avvicina.

Attesa per un fix via aggiornamento software

La buona notizia è che trattandosi di un problema software, OPPO dovrebbe essere in grado di risolverlo tramite un aggiornamento firmware. Gli utenti si aspettano che l’azienda intervenga rapidamente, idealmente prima che il dispositivo arrivi nei mercati globali. Al momento non è stato rilasciato alcun aggiornamento correttivo ufficiale.

Nel 2026, chi sviluppa agenti AI si trova inevitabilmente a fare i conti con tre acronimi: MCP, A2A e AG-UI. La domanda più comune è: sono standard in competizione tra loro? Devo usarli tutti e tre? Quale mi serve davvero?

La risposta breve è che non competono affatto — si completano. Ciascuno risolve un problema diverso a un livello diverso dell’architettura degli agenti. Un’analogia utile: pensateli come TCP, HTTP e HTML nel web — protocolli che operano a strati diversi e insieme rendono possibile il funzionamento del sistema.

Il quadro d’insieme

Prima di entrare nel dettaglio, ecco una tabella riassuntiva:

MCP — Il layer degli strumenti

Il problema che risolve

Il vostro agente deve fare cose concrete: interrogare un database, chiamare un’API, leggere un file, cercare sul web. Prima di MCP, ogni integrazione era custom: codice ad hoc per ogni strumento, ogni framework, ogni modello. MCP standardizza tutto questo in un unico protocollo.

Come funziona

MCP usa un’architettura client-server basata su JSON-RPC 2.0. Il server MCP espone:

• Tools: funzioni che il modello può invocare, con nome, descrizione e schema tipizzato degli input
• Resources: dati in sola lettura che l’agente può consultare (schemi DB, file di configurazione)
• Prompts: template riutilizzabili

Il client MCP — tipicamente integrato nel framework dell’agente — scopre queste capacità e le invoca per conto del modello. I transport sono flessibili: stdio per tool locali (subprocess), Streamable HTTP per deployment remoti in produzione.

Quando usarlo

Usate MCP ogni volta che il vostro agente deve interagire con sistemi esterni: database, API REST, file system, servizi cloud. Se state wrappando un’API esistente per renderla accessibile agli agenti, MCP è il protocollo giusto. L’ecosistema è già maturo: AWS fornisce server MCP open source per S3, DynamoDB, CloudWatch; sono disponibili server per GitHub, Slack, PostgreSQL e decine di altri servizi.

Quando NON usarlo

MCP non è pensato per la comunicazione tra agenti, né per aggiornare interfacce utente. Se avete un agente che deve delegare sotto-task a un altro agente specializzato, quello è territorio di A2A.

A2A — Il layer di collaborazione tra agenti

Il problema che risolve

Avete costruito più agenti specializzati: uno per la ricerca, uno per la generazione di codice, uno per la gestione dei deployment. Come farli collaborare su task complessi senza condividere stato interno, tool o prompt? A2A standardizza come gli agenti si scoprono, delegano task e si scambiano risultati.

Come funziona

A2A usa un modello client-server su HTTP con JSON-RPC 2.0 (e opzionalmente gRPC dalla v0.3). Il principio chiave è l’opacità: gli agenti non espongono i propri internals, pubblicizzano solo ciò che sanno fare.

I concetti fondamentali:

• Agent Cards: documenti JSON ospitati su /.well-known/agent.json che descrivono nome, capacità (“skills”), tipi di input/output supportati e requisiti di autenticazione. Un biglietto da visita machine-readable.
• Tasks: l’unità di lavoro. Un client invia un messaggio al remote agent, che crea un task con lifecycle: submitted → working → completed (o failed, canceled).
• Interaction patterns: sincrono per task semplici, SSE (Server-Sent Events) per streaming su task lunghi, webhook per workflow veramente asincroni.

Quando usarlo

A2A brilla nei sistemi multi-agente dove gli agenti non devono condividere stato interno. Pattern comuni:

• Un agente supervisor che delega a specialisti
• Collaborazione cross-organizzazione (il vostro agente che interagisce con quello del vendor)
• Setup multi-framework: un agente LangGraph che coordina un agente CrewAI — grazie all’opacità, non importa cosa c’è “dentro”

Quando NON usarlo

Per agenti singoli che devono solo chiamare tool, A2A aggiunge overhead non necessario. Se avete bisogno di accoppiamento stretto tra agenti (condivisione di memoria o stato), A2A non è lo strumento giusto.

AG-UI — Il layer dell’interfaccia utente

Il problema che risolve

I vostri agenti hanno bisogno di comunicare con gli utenti in tempo reale: messaggi incrementali, aggiornamenti di stato, handoff per l’approvazione umana. Prima di AG-UI, ogni team implementava questo in modo proprietario — WebSocket custom, polling, SSE artigianali.

Come funziona

AG-UI è un protocollo a eventi strutturati che collega il backend dell’agente con il frontend. Definisce un insieme standard di eventi (message chunks, tool calls, state updates, human-in-the-loop requests) che qualsiasi UI può consumare. È leggero — basato su SSE — e disaccoppiato dal framework dell’agente.

Quando usarlo

Ogni volta che il vostro agente ha una UI interattiva: chatbot, assistenti embedded, dashboard con feedback in tempo reale. Se invece l’agente è un job in background senza interazione utente (elaborazione batch, task schedulati), AG-UI aggiunge complessità inutile.

Come si combinano in pratica

Lo stack completo per un sistema agente enterprise tipico appare così:

┌─────────────────────────────────────┐
│           Interfaccia Utente        │
│         (React, Vue, ecc.)          │
└─────────────┬───────────────────────┘
              │ AG-UI (SSE events)
┌─────────────▼───────────────────────┐
│         Agente Principale           │
│    (LangGraph / CrewAI / custom)    │
│                                     │
│  ┌──────────┐    ┌───────────────┐  │
│  │  MCP     │    │     A2A       │  │
│  │ (tools)  │    │ (subagenti)   │  │
│  └──────────┘    └───────────────┘  │
└─────────────────────────────────────┘
         │                 │
    DB, API, File    Agenti Specializzati


Lo stato dell’ecosistema nel 2026

MCP ha vinto il layer dei tool: è supportato da praticamente tutti i framework principali (LangChain, LlamaIndex, AutoGen, Semantic Kernel) e ha un ecosistema di centinaia di server pre-costruiti. A2A sta emergendo come standard per il layer di coordinamento e la Linux Foundation ne gestisce ora la governance insieme a MCP. AG-UI è più giovane ma sta guadagnando terreno rapidamente grazie all’integrazione con CopilotKit e framework React.

La combinazione dei tre è sempre più considerata il baseline atteso per deployment agente enterprise — come HTTP, TLS e OAuth sono diventati il baseline per i servizi web.

Conclusione

Se state iniziando a costruire agenti AI, ecco un percorso pragmatico:

1. Iniziate con MCP — è maturo, ha un ecosistema enorme e copre la maggior parte dei casi d’uso con un singolo agente
2. Aggiungete A2A quando avete più agenti specializzati che devono collaborare
3. Integrate AG-UI solo se l’agente ha una UI interattiva che richiede aggiornamenti in tempo reale

La buona notizia è che questi protocolli sono progettati per coesistere: adottarli incrementalmente è la strategia giusta.

Fonte originale: The Agent Protocol Stack: MCP vs. A2A vs. AG-UI (DZone) — approfondito con ulteriori riferimenti da Dev.to e subhadipmitra.com.

Tre anni fa il vostro team ha costruito un’integrazione di pagamento. Funzionava perfettamente. Poi siete passati a una soluzione migliore, avete rilasciato la nuova versione e tutti si sono dedicati al progetto successivo. Nessuno ha aperto un ticket formale per disattivare il vecchio endpoint. Nessuno ci ha nemmeno pensato.

Quell’endpoint probabilmente sta ancora girando adesso. Benvenuti nel problema delle Zombie API.

Cosa sono le Zombie API

Una Zombie API è un’interfaccia applicativa che rimane accessibile ma che l’organizzazione non monitora più, non aggiorna e non supporta ufficialmente. Continua a funzionare in background, risponde alle richieste, restituisce dati — ma nessuno la presidia. Può trattarsi di:

• Un’API versione 1 dimenticata dopo il lancio della v2
• Un endpoint di test mai rimosso dall’ambiente di produzione
• Un’integrazione con un sistema esterno deprecato ma mai formalmente chiusa
• Un servizio interno esposto durante uno sprint e poi lasciato lì

La differenza rispetto alle Shadow API è sottile ma importante: le Shadow API sono endpoint mai documentati ufficialmente (spesso creati da sviluppatori senza seguire i processi aziendali); le Zombie API sono endpoint che erano ufficiali, ma sono sopravvissute alla loro utilità.

Perché le Zombie API sono pericolose

1. Controlli di sicurezza obsoleti

Le Zombie API nascono in un’epoca diversa. Possono ancora utilizzare meccanismi di autenticazione deboli come API key in plaintext, HTTP Basic Auth senza HTTPS, o sessioni senza scadenza. Non hanno mai ricevuto le patch per le vulnerabilità scoperte negli anni successivi alla loro creazione. I framework e le librerie che usano sono datati, spesso con CVE note e non risolte.

# Esempio: vecchio endpoint con autenticazione debole
GET /api/v1/payments?user_id=1234&token=abc123
# Nessuna validazione token server-side, nessun rate limiting,
# nessun log di accesso attivo


2. Assenza di monitoraggio

Gli endpoint zombie non compaiono nei dashboard di osservabilità, non generano alert, non vengono inclusi nei penetration test periodici. Eppure continuano a restituire dati: record di clienti, token di sessione, informazioni di sistema. Le violazioni che li coinvolgono possono passare inosservate per mesi.

3. Superficie di attacco invisibile

Dal punto di vista del team di sicurezza, l’endpoint non esiste. Dal punto di vista di un attaccante, invece, è perfettamente raggiungibile. Gli scanner automatici — e nel 2026 sempre più spesso gli agenti AI autonomi — individuano questi endpoint attraverso pattern comuni: /api/v1/, /api/legacy/, file Swagger dimenticati, entry in file robots.txt.

4. Il vettore degli agenti AI

Una dimensione nuova nel 2026: i sistemi agentic AI che chiamano autonomamente API per completare task possono scoprire e interagire con endpoint zombie che il team di sicurezza umano non ha mai pensato di inventariare. Un agente che esegue fuzzing automatico o che segue link nei file di documentazione può “risvegliare” endpoint che nessuno controllava da anni.

Come identificare le Zombie API nel vostro ambiente

Inventario tramite discovery automatica

Il primo passo è vedere ciò che non si riesce a vedere. Strumenti come OWASP ZAP, Burp Suite, o soluzioni enterprise come Noname Security, Salt Security e Traceable AI possono scansionare il traffico di rete per identificare endpoint che ricevono richieste ma non compaiono nella documentazione ufficiale.

# Con curl e grep: cerca pattern di API versionate nei log
grep -E "/api/v[0-9]+/" /var/log/nginx/access.log |   awk '{print $7}' | sort | uniq -c | sort -rn | head -50


Analisi del codice sorgente

Una scansione statica del codice può estrarre tutti i route definiti nell’applicazione e confrontarli con quelli registrati nel gateway API. La differenza è la lista candidata di zombie (o shadow).

# Esempio con grep per trovare route Express.js
grep -rE "app\.(get|post|put|delete|patch)\s*\(" ./src   | grep -oP "(?

Analisi del traffico reale

Anche se un endpoint non viene più mantenuto, potrebbe ancora ricevere traffico — da client legacy, da integrazioni di partner non aggiornate, o da attaccanti che lo scandagliano. Analizzare i log di accesso degli ultimi 90-180 giorni rivela endpoint “morti” che in realtà rispondono ancora.

Come mitigare il rischio

Governance del ciclo di vita delle API

La soluzione strutturale è implementare un API lifecycle management formale, con quattro fasi chiare:

1. Active: l’API è in produzione, monitorata e manutenuta
2. Deprecated: l’API funziona ancora ma è stata annunciata la dismissione. I client ricevono header Deprecation e Sunset in ogni risposta
3. Sunset: la data di dismissione è imminente, le richieste restituiscono warning espliciti
4. Retired: l’endpoint è stato disattivato, risponde con 410 Gone

# Header HTTP di deprecazione (RFC 8594)
HTTP/1.1 200 OK
Deprecation: Sat, 31 Dec 2025 23:59:59 GMT
Sunset: Sat, 30 Jun 2026 23:59:59 GMT
Link: <https://api.example.com/v2/payments>; rel="successor-version"


Applicate il principio del minimo privilegio anche alle API

Le API che non sono più in uso attivo non dovrebbero avere accesso ai sistemi di produzione. Prima di decommissionare formalmente, rimuovete le credenziali, revocate i token di accesso e isolate l’endpoint dalla rete interna.

Automatizzate il testing di sicurezza su tutto l’inventario

Il penetration test periodico deve includere anche gli endpoint “vecchi”. Configurate scanner DAST (Dynamic Application Security Testing) per coprire l’intero inventario API, non solo gli endpoint documentati nella versione corrente.

# Esempio con OWASP ZAP via CLI
docker run -t owasp/zap2docker-stable zap-api-scan.py   -t https://api.example.com/api/v1/openapi.yaml   -f openapi   -r zap-report.html


Risk scoring degli endpoint

Non tutti gli endpoint zombie hanno lo stesso livello di rischio. Prioritizzate in base a:

• Metodo di autenticazione (nessuna > API key > OAuth 2.0)
• Sensibilità dei dati esposti (PII, dati finanziari, credenziali)
• Esposizione a traffico esterno vs. solo interno
• Presenza di vulnerabilità note nel framework usato
• Volume e origine del traffico recente

Un piano d’azione in tre settimane

Per team che vogliono affrontare il problema in modo pragmatico:

Settimana 1 — Discovery: Eseguite una scansione completa del traffico degli ultimi 90 giorni. Estraete tutti gli endpoint dal codice sorgente. Confrontate con il registro ufficiale dell’API gateway.

Settimana 2 — Triage: Per ogni endpoint non documentato, determinate se è un’API shadow (mai documentata) o zombie (precedentemente documentata). Applicate il risk scoring. Identificate i proprietari originali tramite git blame o cronologia dei ticket.

Settimana 3 — Remediation: Gli endpoint ad alto rischio vanno disabilitati immediatamente. Per quelli con traffico ancora attivo, notificate i client e stabilite una data di sunset. Implementate il processo di governance per prevenire il problema in futuro.

Conclusione

Le Zombie API non sono un problema teorico. Sono un debito tecnico e di sicurezza reale, spesso invisibile, che cresce silenziosamente ad ogni rilascio. Con l’aumento dei sistemi agentic AI che interagiscono autonomamente con le API, il rischio di “risvegliare” questi endpoint aumenta ulteriormente.

La buona notizia è che il problema è risolvibile con processi ben definiti: discovery sistematico, governance del ciclo di vita, e testing automatizzato su tutto l’inventario — non solo sulla versione corrente dell’API.

Non aspettate che sia un attaccante a scoprire cosa avete dimenticato.

Fonte originale: The “Zombie API” Attack: Why Your Old Integrations Are Your Biggest Security Risk (DZone) — approfondito con riferimenti da Salt Security, GetAstra e Checkmarx.

Sony ha ufficialmente presentato Xperia 1 VIII il 13 maggio, e il nuovo design — con il modulo fotocamere quadrato che rompe la storica disposizione verticale — aveva già scatenato reazioni contrastanti in rete. Eppure, un sondaggio condotto su X (ex Twitter) rivela che la stragrande maggioranza degli utenti non ha cambiato idea sull’acquisto proprio a causa dell’estetica.

I risultati del sondaggio

Il sondaggio, che chiedeva se il nuovo design influenzasse la decisione d’acquisto, ha restituito risultati sorprendenti:

• 44,3% — “Lo comprerei comunque, indipendentemente dal design”
• 21,7% — “Non lo comprerei comunque”
• 18,9% — “Mi piace il nuovo design, quindi lo compro”
• 15,1% — “Non mi piace il nuovo design, quindi non lo compro”

Il design non è il fattore decisivo

Il dato più rilevante è che quasi il 45% degli intervistati dichiara di voler acquistare Xperia 1 VIII indipendentemente dall’estetica. Gli utenti Xperia sono tradizionalmente fedeli per ragioni legate alle prestazioni: fotocamera, audio di qualità, compatibilità con le SD card, tasto fisico per lo scatto. Il design, per quanto possa fare discutere, non è evidentemente un dealbreaker.

Chi ama il nuovo stile supera chi lo rifiuta

Interessante anche notare come la percentuale di chi acquisterà il telefono proprio grazie al nuovo design (18,9%) sia superiore a chi rinuncia all’acquisto per lo stesso motivo (15,1%). In sostanza, il cambio estetico porta più utenti che non ne allontana. Un segnale che Sony, pur avendo cambiato rotta rispetto alla tradizione, potrebbe aver fatto una scelta azzeccata anche in termini di mercato.

È ufficiale: anche lo Xperia 1 VIII di Sony è prodotto in Cina, esattamente come il modello precedente Xperia 1 VII. La conferma arriva dalle informazioni pubblicate dall’operatore di Hong Kong CSL Mobile, che ha esplicitamente indicato la Cina come paese di fabbricazione. Questo dato smonta le speculazioni delle scorse settimane che ipotizzavano uno spostamento della produzione a Taiwan.

La “pista taiwanese” si rivela una falsa notizia

In precedenza, alcuni siti avevano riportato — basandosi su documentazione FCC — che la certificazione di Xperia 1 VIII fosse stata gestita da una società diversa rispetto al solito, alimentando l’ipotesi di una transizione produttiva verso Taiwan o altri paesi fuori dalla Cina. L’informazione di CSL Mobile smentisce questa ricostruzione: Sony continua a far produrre il suo flagship Android in Cina, attraverso lo stesso schema di outsourcing adottato con Xperia 1 VII.

La fine della produzione Sony in Thailandia

Per anni gli smartphone Xperia erano stati assemblati nello stabilimento Sony Technology Thailand, storica fabbrica del gruppo in Asia. Con il progressivo ritiro di Sony dalla produzione diretta di smartphone, l’azienda ha abbandonato quella struttura e affidato la manifattura a partner esterni cinesi già a partire dallo Xperia 1 VII. Lo stesso modello organizzativo si conferma ora per l’VIII generazione.

La continuità nella filiera produttiva suggerisce che Sony non stia pianificando cambiamenti radicali nella supply chain per il suo flagship Android, almeno nel breve termine.

L’aggiornamento ad Android 16 per il Motorola Moto g66y 5G è stato temporaneamente sospeso dall’operatore giapponese Y!mobile. Il motivo? Dopo l’installazione dell’update sono emersi problemi tecnici che hanno richiesto uno stop precauzionale alla distribuzione, con data di ripresa ancora da definire.

L’aggiornamento era disponibile dallo scorso aprile

L’update ad Android 16 per il Moto g66y 5G era stato reso disponibile a metà aprile 2026. Tuttavia, il 12 maggio, Y!mobile ha pubblicato un avviso ufficiale in cui comunicava la sospensione immediata della distribuzione a causa del rilevamento di alcune criticità post-aggiornamento. Non è stata fornita una data per la ripresa dei rilasci.

Problemi di connettività eSIM segnalati dagli utenti

Sebbene il collegamento diretto tra la sospensione e i bug di connettività non sia stato confermato ufficialmente, sul modello SIM-free correlato Moto g66j 5G gli utenti hanno segnalato numerosi problemi di rete dopo l’installazione di Android 16. In particolare sono stati riportati:

• Impossibilità di connettere la eSIM dati di operatori MVNO
• Instabilità nella selezione della rete mobile
• Interruzioni intermittenti della connessione dati

Cosa fare se si è già aggiornati

Gli utenti che hanno già installato l’aggiornamento e riscontrano problemi con la eSIM sono invitati a contattare l’assistenza di Motorola o dell’operatore. Chi non ha ancora effettuato l’update è consigliato di attendere la ripresa ufficiale della distribuzione, che porterà presumibilmente una versione corretta del firmware. Motorola non ha ancora rilasciato comunicazioni ufficiali in merito.

Xiaomi ha rivelato di aver sviluppato e quasi lanciato uno smartphone ultrasottile per competere con iPhone Air di Apple, salvo poi abbandonare il progetto all’ultimo momento. La scelta, annunciata dal presidente del gruppo Lv Weibing, mette in luce una filosofia aziendale centrata sull’esperienza d’uso reale piuttosto che sulle specifiche estetiche.

Il progetto era arrivato quasi alla produzione di massa

Stando a quanto dichiarato da Lv Weibing durante una diretta streaming, Xiaomi aveva portato lo sviluppo del suo smartphone ultrasottile in una fase avanzatissima, arrivando quasi alla produzione in serie. Nonostante ciò, il management ha deciso di fermare tutto e non commercializzare il dispositivo.

Il problema centrale era di natura tecnica: ridurre eccessivamente lo spessore di uno smartphone comporta inevitabili compromessi in termini di capacità della batteria, dissipazione termica e possibilità di integrare processori di fascia alta. Il risultato sarebbe stato un prodotto dall’aspetto accattivante ma con prestazioni quotidiane insoddisfacenti.

L’usabilità prima del design

Xiaomi ha scelto di non inseguire la moda della sottigliezza estrema, preferendo mantenere standard elevati in termini di autonomia, raffreddamento e potenza di calcolo. Una scelta che si scontra con la tendenza di mercato avviata da Apple con l’iPhone Air, ma che punta a soddisfare le esigenze pratiche degli utenti nel lungo periodo.

Il futuro è nella linea “Max”

La strategia futura di Xiaomi si orienta invece verso la linea “Max”, pensata non solo come dispositivo a schermo più grande, ma come piattaforma completa con fotocamere potenziate, prestazioni superiori e batterie di grande capacità. Una visione opposta a quella della leggerezza estrema, che punta invece sulla sostanza.

Con questa scelta, Xiaomi si distingue volutamente dalla corsa alla sottigliezza che sembra coinvolgere altri produttori, posizionandosi come brand che mette le prestazioni reali davanti all’estetica.

Ogni settimana, il mondo del software libero e open source ci offre una moltitudine di aggiornamenti e nuove versioni di software. Anche se non tutti sono di grande rilevanza, molti di questi possono risultare...

🔗 Leggi il post completo

Debian è una delle distribuzioni GNU/Linux più longeve e rispettate al mondo, nata nel 1993 grazie al lavoro di Ian Murdock, giovane studente dell’Università Purdue che decise di creare un sistema operativo completamente libero,...

🔗 Leggi il post completo

Due nuovi dispositivi Xiaomi fanno capolino nel database GSMA: si tratta di Redmi 17 e POCO C95 Pro, entrambi registrati con codici modello diversi rispetto a quanto era trapelato in precedenza. Una variazione che potrebbe indicare modifiche alla configurazione hardware o alla strategia commerciale dei due smartphone.

I nuovi codici modello

Ecco le sigle ufficialmente registrate presso GSMA:

• Redmi 17: 2606FRN72Y / 2606FRN72L
• POCO C95 Pro: 2606FPC72Y / 2606FPC72L

Questi codici differiscono significativamente da quelli emersi in precedenti leak, che indicavano come base di sviluppo il codename “zephyr – P19A”. Il cambio di codice suggerisce che i modelli abbiano subito revisioni durante il percorso di sviluppo.

Cosa potrebbe essere cambiato

Nel settore mobile, una modifica al codice modello durante lo sviluppo spesso segnala variazioni sostanziali come un cambio di chipset, una revisione della configurazione delle memorie o un riposizionamento nel mercato. Nel contesto attuale, segnato da pressioni sulle filiere dei semiconduttori, non è raro che i produttori debbano adattare le proprie scelte in corsa.

Per POCO C95 Pro, in particolare, ci si aspetta un posizionamento nella fascia economica del mercato, dove ogni variazione di componente può avere un impatto significativo sul prezzo finale. Ulteriori dettagli sulle specifiche tecniche emergeranno con i prossimi leak e le certificazioni aggiuntive.

Samsung si prepara ad espandere la sua gamma mid-range con il Galaxy M47, comparso nelle ultime ore sul database di benchmark Geekbench. La scheda tecnica del dispositivo inizia a prendere forma: a bordo ci saranno il chip Snapdragon 6 Gen 3 di Qualcomm e il sistema operativo Android 16.

Le specifiche tecniche emerse dal benchmark

Il Galaxy M47 è apparso su Geekbench con la sigla SM-M476B. Ecco le specifiche confermate:

• Chipset: Snapdragon 6 Gen 3
• CPU: octa-core (4 core da 2,40 GHz + 4 core da 1,80 GHz)
• GPU: Adreno 710
• Sistema operativo: Android 16
• Score OpenCL GPU: 2256

Un mid-range aggiornato per il mercato globale

Lo Snapdragon 6 Gen 3 è un chip pensato per la fascia media, capace di offrire buone prestazioni in uso quotidiano e nel gaming casual. La scelta di Android 16 come sistema operativo di serie rappresenta un segnale positivo in termini di aggiornamenti software a lungo termine.

La serie Galaxy M è tradizionalmente orientata ai mercati emergenti, ma spesso i modelli trovano spazio anche in Europa. Per i dettagli completi su memoria, fotocamera e prezzo, bisognerà attendere l’annuncio ufficiale di Samsung, che non ha ancora comunicato una data di presentazione.

Buone notizie per i possessori di Xiaomi 13T: l’aggiornamento a HyperOS 3 basato su Android 16 sembra finalmente avvicinarsi. Nuovi build interni sono stati scoperti nelle ultime ore, segnale che i test stanno entrando nella fase conclusiva prima del rilascio stabile.

I build scoperti

I build individuati per Xiaomi 13T sono i seguenti:

• Versione EEA (Europa): OS3.0.1.0.WMFEUXM — codename aristotle_eea_global
• Versione Global: OS3.0.3.0.WMFMIXM — codename aristotle_global

Entrambi sono basati su Android 16 e si trovano ancora in fase di test interno, ma la loro esistenza conferma che Xiaomi sta lavorando attivamente al rilascio stabile.

Un’attesa lunga per gli utenti Xiaomi 13T

Gli utenti di Xiaomi 13T aspettano HyperOS 3 da diversi mesi, mentre molti altri dispositivi del brand hanno già ricevuto l’aggiornamento. La situazione ha generato frustrazione nella community, soprattutto considerando che il 13T è un modello ancora recente e venduto in Europa.

La scoperta dei nuovi build è un segnale incoraggiante: di solito, quando vengono individuate build interne in fase avanzata, il rilascio per i beta tester e successivamente per tutti gli utenti avviene nel giro di alcune settimane. Restate sintonizzati per aggiornamenti.

RedMagic alza l’asticella del gaming su smartphone con il suo prossimo RedMagic 11S Pro, in arrivo in Cina il 18 maggio. Le ultime anticipazioni rivelano specifiche sorprendenti: un emulatore PC integrato, il supporto a Steam e una batteria monstre da 8000 mAh, per un dispositivo Android pensato per portare l’esperienza del gaming su PC in tasca.

Un emulatore PC con motore di conversione X86

La caratteristica più sorprendente è l’emulatore PC proprietario sviluppato da RedMagic, dotato di un motore di conversione X86 che permette di eseguire giochi per PC direttamente sullo smartphone. La funzione Steam Direct Mode consente di:

• Collegare il proprio account Steam
• Sincronizzare i salvataggi di gioco
• Giocare in cross-platform con le versioni PC

Batteria da 8000 mAh e hardware flagship

Per supportare sessioni di gioco intense, RedMagic ha dotato l’11S Pro di una batteria da 8000 mAh, una capacità rara persino nel segmento gaming phone. Abbinata a un chipset di livello flagship e al sistema di raffreddamento avanzato tipico dei device RedMagic, dovrebbe garantire ore di gioco senza preoccupazioni.

Il RedMagic 11S Pro si propone come uno smartphone Android dalla vocazione fortemente gaming-PC, un segmento di nicchia ma in crescita che punta ad attrarre i giocatori PC che cercano la stessa esperienza in formato tascabile.

A meno di ventiquattr’ore dalla pubblicazione del report ESET, emerge l’ennesima prova che il conflitto russo-ucraino si combatte su due fronti: quello fisico e quello cibernetico. Il gruppo Ghostwriter — noto anche come FrostyNeighbor, UNC1151, Storm-0257 e White Lynx — ha intensificato le proprie operazioni contro le istituzioni di Kiev, adottando una catena d’attacco sempre più sofisticata che combina phishing mirato, geofencing intelligente e payload a più stadi. La notizia, pubblicata il 14 maggio 2026 da The Hacker News sulla base della ricerca ESET, arriva mentre le operazioni cinetiche nel conflitto rimangono attive.

Chi è Ghostwriter / FrostyNeighbor

Ghostwriter è un APT attivo almeno dal 2016, ritenuto allineato con i servizi d’intelligence bielorussi. Nel corso degli anni ha condotto sia operazioni di cyberspionaggio che campagne di influenza — disinformazione, hack-and-leak, manipolazione di contenuti — contro Ucraina, Polonia, Lituania ed Estonia. ESET lo traccia con il moniker FrostyNeighbor; altri vendor lo conoscono come PUSHCHA, TA445, UAC-0057 o Umbral Bison. Il gruppo ha dimostrato una notevole capacità di adattamento: ogni campagna aggiorna strumenti e metodi di consegna per sfuggire ai sistemi di detection.

La nuova catena d’attacco: geofencing e PDF-esca

Le attività osservate da marzo 2026 evidenziano un salto qualitativo rispetto alle campagne precedenti. Il vettore iniziale è uno spear-phishing con allegato PDF che impersona la società di telecomunicazioni ucraina Ukrtelecom — un mittente di apparente legittimità per qualsiasi funzionario governativo di Kiev.

La caratteristica tecnica più rilevante è il geofencing lato server: quando il destinatario apre il PDF e clicca sul link incorporato, il server degli attaccanti verifica l’indirizzo IP del richiedente. Se l’IP non corrisponde a una geolocalizzazione ucraina, il server restituisce un documento PDF benigno e inoffensivo. Questa tecnica rende l’analisi in sandbox — tipicamente eseguita da infrastrutture cloud non ucraine — completamente inefficace, poiché l’analista riceverà sempre il file pulito.

Catena d’infezione a tre stadi

Per le vittime che superano il controllo geografico, il link nel PDF scarica un archivio RAR contenente un payload JavaScript. L’esecuzione di questo script avviene in parallelo su due binari:

• Visualizzazione del documento-esca: viene aperto un file lure convincente per mantenere la credibilità dell’allegato originale.
• Lancio di PicassoLoader: il downloader JavaScript viene eseguito in background, avviando il secondo stadio dell’attacco.

PicassoLoader, già noto dall’arsenale di Ghostwriter, svolge una funzione cruciale di fingerprinting e profilazione dell’host: raccoglie informazioni sul sistema (hostname, utente, sistema operativo, processi attivi, configurazione di rete) e le trasmette all’infrastruttura C2 degli attaccanti ogni 10 minuti. Questa telemetria consente agli operatori di valutare manualmente se la vittima è di interesse strategico.

Solo in caso di risposta affermativa da parte degli operatori, viene inviato un terzo stadio: un dropper JavaScript che installa il Cobalt Strike Beacon — il framework di post-exploitation preferito dagli APT di ogni nazionalità, qui usato per stabilire accesso persistente, esfiltrare dati e muoversi lateralmente nella rete della vittima.

Targeting selettivo: militare, difesa, governo

Secondo ESET, il targeting principale si concentra su organizzazioni militari, del settore difesa e governative in Ucraina. In Polonia e Lituania la campagna mostra un profilo vittimologico più ampio, includendo anche manifatturiero, healthcare, logistica e governo. Questa distinzione suggerisce che in Ucraina le operazioni abbiano un obiettivo di intelligence preciso — raccolta di informazioni militari e governative strategiche — mentre altrove Ghostwriter opera con una rete più larga, probabilmente per mantenere accesso a lungo termine in ottica NATO.

Il contesto più ampio: Gamaredon e BO Team

Le rivelazioni su FrostyNeighbor si inseriscono in un panorama di operazioni cyber parallele nel teatro ucraino. Contestualmente, il gruppo russo Gamaredon — attivo con campagne di spear-phishing contro istituzioni statali ucraine dal settembre 2025 — sta distribuendo GammaDrop e GammaLoad tramite archivi RAR che sfruttano la vulnerabilità CVE-2025-8088. HarfangLab descrive Gamaredon come un attore non sofisticato ma straordinariamente persistente, con un tempo operativo e una scala d’attacco difficilmente eguagliabili.

Sul fronte opposto, il gruppo filoukraino BO Team (alias Black Owl) starebbe collaborando con Head Mare (PhantomCore) in attacchi contro organizzazioni russe, impiegando backdoor come BrockenDoor, ZeronetKit e il nuovo ZeroSSH — un backdoor Go-based capace di stabilire canali SSH inversi e di compromettere anche sistemi Linux.

Indicatori di Compromissione

# Tattiche, Tecniche e Procedure (TTPs) - Ghostwriter / FrostyNeighbor (Marzo 2026)
## Vettore iniziale
- Spear-phishing con allegato PDF
- Lure document: impersonificazione Ukrtelecom
## Tecniche di evasione
- Geofencing IP lato server (solo IP ucraini ricevono payload malevolo)
- Anti-sandbox tramite user-agent check lato server
## Payload chain
1. PDF → link → server geofenzato
2. Archivio RAR → payload JavaScript
3. JavaScript → PicassoLoader (JavaScript variant)
4. PicassoLoader → fingerprint host (ogni 10 min → C2)
5. [Operatore approva] → JavaScript dropper → Cobalt Strike Beacon
## Malware families
- PicassoLoader (JavaScript variant, nuova versione 2026)
- Cobalt Strike Beacon
## Targeting primario
- Organizzazioni militari ucraine
- Settore difesa ucraino  
- Enti governativi ucraini
- Target secondari: Polonia, Lituania (industria, healthcare, logistica)
## Riferimenti
- ESET Research: FrostyNeighbor report, maggio 2026
- Tracking alias: UNC1151, Storm-0257, TA445, UAC-0057, PUSHCHA, White Lynx, Umbral Bison

Due righe per i difensori

La sofisticazione del geofencing rende inutili molte tecniche di sandboxing tradizionale. I team di difesa ucraini e dei paesi NATO nel mirino dovrebbero adottare le seguenti contromisure. Innanzitutto, simulare il download dei link presenti in PDF sospetti utilizzando proxy IP con geolocalizzazione ucraina, in modo da bypassare il filtro geografico e ottenere il payload reale. In secondo luogo, monitorare le connessioni HTTP/HTTPS in uscita ogni 10 minuti verso IP non noti, potenziale segnale di PicassoLoader in fase di beaconing. In terzo luogo, applicare una politica zero-trust sull’esecuzione di JavaScript tramite applicazioni utente: la catena d’infezione si basa interamente su JS. Infine, formare il personale governativo e militare a riconoscere le impersonificazioni di fornitori di servizi (come Ukrtelecom) come vettore di phishing ad alta credibilità.

Il report ESET sintetizza efficacemente la sfida: “FrostyNeighbor rimane un threat actor persistente e adattivo, con un elevato livello di maturità operativa. Il payload viene consegnato solo dopo una validazione lato server che combina controlli automatizzati con la validazione manuale degli operatori”. Una minaccia ibrida — tecnologica e umana — che richiede una risposta altrettanto ibrida.

C’è una certa ironia nel vedere un gruppo ransomware diventare esso stesso vittima di una violazione dei dati. Il 4 maggio 2026, gli operatori di The Gentlemen — il secondo gruppo ransomware più attivo al mondo nel 2026 con oltre 400 vittime pubbliche — hanno dovuto ammettere sui forum underground che il loro database backend era stato compromesso. Check Point Research ha ottenuto una porzione di quei dati prima che venissero rimossi, producendo uno dei dossier più dettagliati mai pubblicati sull’anatomia interna di un’organizzazione RaaS moderna.

L’ascesa fulminante di un gruppo che usava l’AI per sviluppare ransomware

The Gentlemen è emerso nel panorama del cybercrime organizzato con una velocità insolita. Nei soli primi mesi del 2026 ha rivendicato oltre 240 attacchi, raggiungendo il secondo posto globale per numero di vittime secondo il Q1 2026 Ransomware Report di Check Point Research. Una crescita che non è casuale: gli analisti hanno documentato l’uso sistematico di assistenti AI per accelerare lo sviluppo del ransomware, riducendo drasticamente i tempi tra ideazione e deployment dei payload.

Il modello operativo è quello classico del Ransomware-as-a-Service: un nucleo di operatori gestisce la piattaforma, la crittografia, la negoziazione e l’infrastruttura, mentre affiliati terzi si occupano dell’accesso iniziale e del deploy nei sistemi delle vittime. Ciò che distingue The Gentlemen è la sofisticazione organizzativa e la velocità con cui ha scalato le operazioni.

La violazione: come un provider di hosting ha esposto tutto

La compromissione è stata possibile attraverso il provider di hosting 4VPS, utilizzato dal gruppo per gestire parti della propria infrastruttura backend. Una scelta operativa che si è rivelata fatale: quando 4VPS è stato compromesso, con esso è caduta anche la protezione dei database di The Gentlemen. L’annuncio è arrivato dai criminali stessi sui forum underground il 4 maggio 2026 — una mossa inusuale che testimonia quanto grave fosse la situazione.

Check Point Research è riuscita a recuperare una porzione significativa del database prima della rimozione. Il materiale ottenuto include chat interne tra operatori, roster organizzativi, trascrizioni di negoziazioni con le vittime, discussioni sugli strumenti e documentazione sulle infrastrutture utilizzate. Un tesoro informativo che i ricercatori hanno condiviso con le forze dell’ordine, con un’indagine in corso.

Anatomia di una gang: l’organigramma esposto

Il leak ha rivelato che il gruppo è gestito da circa nove operatori nominati, organizzati attorno a un singolo amministratore identificato con gli alias zeta88 e hastalamuerte. Questo profilo non è quello di un principiante: si tratta di un ex affiliato del programma ransomware Qilin, che ha imparato il mestiere sotto un’organizzazione consolidata prima di costruire una struttura concorrente. Una progressione di carriera nel crimine organizzato digitale che rispecchia schemi già visti con altre gang.

L’amministratore non si limita alla gestione della piattaforma, ma partecipa personalmente agli eventi di cifratura — un livello di coinvolgimento diretto insolito per gruppi di questa dimensione, dove solitamente il livello apicale delega completamente le operazioni tattiche agli affiliati. I log di chat mostrano un’organizzazione gerarchica con ruoli definiti: chi gestisce le trattative, chi monitora l’infrastruttura C2, chi coordina gli affiliati.

L’arsenale tecnico: SystemBC, GPO deployment e supply chain pivot

Dal punto di vista tecnico, il report di Check Point descrive una catena di attacco matura. Il punto di ingresso osservato in almeno un incident response tracciato è un Domain Controller già compromesso con privilegi Domain Admin. Da questa posizione, gli attaccanti eseguono una ricognizione sistematica della rete, utilizzando strumenti open-source come gogo per lo scanning automatizzato, validano le credenziali su tutti i sistemi raggiungibili e preparano il terreno per il deploy del payload.

Lo strumento chiave per la fase di persistenza e tunneling è SystemBC, un proxy malware che stabilisce tunnel SOCKS5 cifrati (RC4) verso il server C2 e consente il download e l’esecuzione di payload aggiuntivi, sia su disco che iniettati direttamente in memoria. Un C2 server SystemBC analizzato da Check Point ha rivelato un botnet di oltre 1.570 vittime, con un profilo di infezione orientato prevalentemente verso ambienti corporate.

Il deployment finale del ransomware avviene tramite Group Policy Object (GPO): il binario viene configurato per eseguirsi su tutti i sistemi domain-joined durante il refresh delle policy, producendo un evento di cifratura quasi simultaneo sull’intero dominio — massimizzando il danno e minimizzando la finestra di risposta per i difensori.

Particolarmente rilevante è un attacco documentato nell’aprile 2026 contro una software consultancy britannica: dopo aver violato questa azienda, The Gentlemen ha utilizzato i dati rubati — documentazione infrastrutturale, credenziali, informazioni sugli accessi dei clienti — per condurre un attacco successivo contro uno dei clienti della consultancy in Turchia. Un caso concreto di supply chain pivot che dimostra come il valore di un’intrusione non si misuri solo nei dati esfiltrati, ma nei vettori di attacco secondari che abilita.

Due righe per i difensori: cosa fare dopo questa disclosure

La violazione di The Gentlemen è un evento raro ma istruttivo. Il leak rivela tattiche, procedure e persino identità che possono supportare attività di threat intelligence proattiva. Alcuni elementi pratici: monitorare le connessioni SOCKS5 non autorizzate verso IP esterni; implementare alert su modifiche ai GPO che includono eseguibili non firmati; verificare l’integrità dei Domain Controller come primo indicatore di compromissione avanzata; e applicare il principio del minimo privilegio per limitare il blast radius nel caso di compromise di un affiliato o fornitore.

Check Point ha rilasciato regole YARA per il rilevamento basato su firma del ransomware di The Gentlemen. Per i team SOC, l’integrazione di questi indicatori nelle piattaforme SIEM/SOAR è raccomandata con priorità alta, data la velocità con cui il gruppo ha dimostrato di scalare le operazioni.

Indicatori di Compromissione (IoC)

# The Gentlemen Ransomware - IoC e TTPs
# Fonte: Check Point Research (maggio 2026)
## Tecniche MITRE ATT&CK
T1078 - Valid Accounts (credenziali rubate per lateral movement)
T1021.002 - Remote Services: SMB/Windows Admin Shares
T1484.001 - Group Policy Modification (GPO-based ransomware deployment)
T1090.001 - Proxy: Internal Proxy (SystemBC SOCKS5 tunneling)
T1486 - Data Encrypted for Impact
T1005 - Data from Local System
T1059 - Command and Scripting Interpreter
## SystemBC C2 Communication
Protocollo C2: custom RC4-encrypted SOCKS5
Botnet noto: 1.570+ vittime identificate da singolo C2 server
Caratteristica: payload iniettati in-memory per evasione AV
## Indicatori comportamentali
- Presenza di gogo scanner eseguito da account privilegiati
- Modifiche a GPO esistenti o creazione di nuovi GPO con executables
- Connessioni SOCKS5 in uscita da workstation non-server
- Autenticazioni a cascata originate da Domain Controller
  (pattern: failed auth → successful auth su multipli host)
## Operatore
Alias noti: zeta88, hastalamuerte
Background: ex affiliato Qilin ransomware
Infrastruttura: 4VPS hosting provider (compromesso maggio 2026)
## Nota
# YARA rules disponibili presso Check Point Research:
# https://research.checkpoint.com/2026/thus-spoke-the-gentlemen/

Xiaomi potrebbe sorprendere il mercato con un lancio anticipato del prossimo Redmi K100. Secondo il noto leaker cinese Digital Chat Station, l’intera serie K100 potrebbe arrivare già nel terzo trimestre del 2026, rompendo con la tradizione che vedeva questi dispositivi debuttare verso fine anno.

Una svolta nella strategia di lancio di Redmi

La serie Redmi K è storicamente legata al calendario Qualcomm: i dispositivi venivano lanciati dopo l’annuncio dei nuovi chip Snapdragon di fascia alta, tipicamente a fine anno. Ora però, stando alle informazioni di Digital Chat Station su Weibo, l’intera serie K100 — non solo alcuni modelli — sarebbe destinata a un lancio anticipato nel Q3 2026.

Il leaker ha risposto affermativamente anche alla domanda di un utente che chiedeva se si trattasse di un lancio parziale, confermando che sarà tutta la serie a essere anticipata. Una mossa insolita per Redmi, che potrebbe rispondere alla pressione competitiva di brand come OnePlus e iQOO.

Cosa aspettarsi dalla serie K100

Non ci sono ancora dettagli ufficiali sulle specifiche tecniche, ma la tradizione della serie K lascia attendere un chipset Qualcomm di ultima generazione, display ad alto refresh rate e ricarica rapida. Se il lancio anticipato si confermasse, Redmi K100 potrebbe sfidare la concorrenza proprio nel momento più caldo del mercato estivo, tradizionalmente dominato da altri brand.

Google sta preparando una delle modifiche più significative all’esperienza di chiamata su Android: le telefonate VoIP effettuate tramite app come WhatsApp, Telegram e potenzialmente LINE potrebbero presto essere integrate nella standard app Telefono del sistema operativo. Un cambiamento che semplificherebbe notevolmente la gestione delle comunicazioni su smartphone Android.

Come funzionerà l’integrazione

La novità è legata all’aggiornamento Jetpack Telecom v1.1.0 di Google, che permetterà alle app VoIP di terze parti di registrarsi come fonti di chiamata native nel sistema Android. In pratica, le chiamate ricevute da WhatsApp o Telegram verranno visualizzate e gestite direttamente dall’app Telefono.

Le funzionalità previste includono:

• Cronologia delle chiamate unificata nell’app Telefono
• Richiamata diretta dall’app Telefono verso il numero VoIP
• Reindirizzamento automatico all’app originale al momento della chiamata

Implicazioni per gli utenti italiani

Per gli utenti italiani, l’aspetto più interessante è la possibile inclusione di LINE — largamente diffusa in alcune community — e soprattutto di WhatsApp, che nel nostro Paese è lo strumento di messaggistica e chiamata di gran lunga più utilizzato. Avere tutte le chiamate in un unico posto sarebbe una comodità reale nella gestione quotidiana delle comunicazioni.

L’implementazione dipenderà anche dalla volontà degli sviluppatori delle singole app di adottare le nuove API. Il rilascio è atteso nelle prossime versioni di Android.

Prima ancora del lancio ufficiale, Xperia 1 VIII di Sony si trova al centro di una polemica che riguarda la durabilità del rivestimento della scocca. Alcuni utenti che hanno avuto accesso a unità demo su Reddit segnalano che il caratteristico finish opaco e ruvido del pannello posteriore potrebbe essere più fragile di quanto ci si aspetterebbe da un flagship.

Il rivestimento opaco: un marchio di fabbrica Sony

A partire da Xperia 1 V, Sony ha introdotto un rivestimento posteriore con texture ruvida che migliora la presa e dona al dispositivo un aspetto premium e distintivo. Lo stesso finish è stato mantenuto su Xperia 1 VIII, ma stando alle prime segnalazioni potrebbe presentare un problema di resistenza all’abrasione.

Le segnalazioni da Reddit: il coating si scheggia

Secondo un utente del subreddit r/SonyXperia che ha testato il device, strofinando i bordi del telefono con una forza moderata il rivestimento tende a sfaldarsi. Il problema sembrerebbe più pronunciato nelle colorazioni chiare (bianco/silver), dove la vernice appare meno aderente rispetto alle varianti scure.

È importante sottolineare che si tratta di test su unità dimostrative, che potrebbero non essere perfettamente rappresentative della qualità del prodotto finale. Sony non ha ancora risposto a queste segnalazioni. Sarà fondamentale attendere le unità retail definitive per valutare se il problema sia effettivamente presente e in che misura.

Gestire gli auricolari Bluetooth su GNU/Linux significa spesso dover rinunciare a molte funzioni avanzate: il sistema mostra solo i controlli di base dell’ambiente desktop, lasciando fuori informazioni come il livello della batteria della custodia,...

🔗 Leggi il post completo

Nuova puntata del podcast di Marco’s Box, questa volta dedicata a commentare le principali notizie dal mondo di linux e del software libero e open source. Trovate la puntata su Spotity, Google Podcasts, Anchor, Apple Podcast, Castbox, TuneIn, Amazon Music, Amazon Alexa e YouTube. In alternativa, per ascoltarla sul vostro player preferito, potete aggiungere il […]
L'articolo Il podcast ...

🔗 Leggi il post completo

Una segnalazione allarmante sta circolando nelle ultime ore sul forum Reddit: un utente afferma che il suo Google Pixel 9 avrebbe preso fuoco spontaneamente mentre era nella tasca dei pantaloni. L’episodio, documentato con immagini e video, mostra i danni provocati dalle alte temperature raggiunte dallo smartphone.

La dinamica dell’incidente

Secondo il racconto dell’utente Reddit KindlyCelery9201, il fatto è avvenuto di domenica sera. Lo smartphone era in tasca quando improvvisamente si è sentito un rumore simile a delle scintille. Guardando verso il basso, l’utente ha visto del fumo uscire dalla tasca. Il Pixel 9 è stato lanciato a terra immediatamente, ma era già surriscaldato in modo preoccupante.

Le immagini pubblicate mostrano:

• Resti del materiale della custodia fusi attorno al modulo fotocamera
• Segni di bruciatura e decolorazione sul corpo del telefono
• Un foro nella tasca dei pantaloni causato dal calore

Caso isolato o segnale di un problema più ampio?

Per ora si tratta di una segnalazione singola e non è possibile stabilire se si tratti di un difetto di produzione isolato o di qualcosa di più sistematico. Google non ha ancora commentato l’accaduto.

Episodi simili di surriscaldamento anomalo colpiscono occasionalmente vari modelli di smartphone di diversi produttori, e nella maggior parte dei casi sono riconducibili a difetti della batteria. Sarà importante monitorare se emergeranno ulteriori segnalazioni simili nelle prossime settimane.

Diversi utenti di Pixel Watch stanno segnalando un fastidioso bug che impedisce di visualizzare i dati sul sonno direttamente sull’orologio. Il paradosso della situazione è che il monitoraggio del sonno funziona correttamente: i dati vengono registrati e sono visibili sull’app Fitbit, ma il dispositivo mostra un messaggio di errore come se non ci fossero rilevazioni recenti.

Il problema: “No recent data” sul watch

Il problema è emerso su Reddit, dove diversi possessori di Pixel Watch 2 hanno descritto la stessa esperienza: dopo aver indossato l’orologio durante la notte, al mattino il display mostra il messaggio “No recent data. Wear your watch to sleep”, come se il monitoraggio non fosse avvenuto.

In realtà, controllando l’app Fitbit sullo smartphone, tutti i dati risultano disponibili e corretti:

• Durata del sonno
• Punteggio della qualità del riposo
• Dati sui risvegli notturni

Un bug di visualizzazione, non di rilevazione

L’ipotesi più probabile è che si tratti di un problema di sincronizzazione o visualizzazione lato watch, non di un malfunzionamento del sensore. I dati vengono acquisiti correttamente, ma qualcosa nella comunicazione tra il firmware dell’orologio e l’interfaccia di visualizzazione va storto.

Google non ha ancora rilasciato una dichiarazione ufficiale sulla questione. Nel frattempo, alcuni utenti riferiscono che un riavvio del dispositivo può risolvere temporaneamente il problema, in attesa di un aggiornamento software risolutivo.

Google starebbe lavorando per stabilire un rapporto diretto con TSMC, il principale produttore mondiale di semiconduttori, puntando a ottenere un accesso prioritario ai processi produttivi più avanzati. Un’ambizione che ricorda molto da vicino la strategia di Apple, da sempre considerata cliente privilegiato del colosso taiwanese.

Addio agli intermediari per i chip Google

Attualmente Google si affida a intermediari come MediaTek e Broadcom per la produzione dei suoi chip. Il nuovo obiettivo sarebbe quello di diventare un cliente diretto di primo livello presso TSMC, potendo così negoziare accesso ai nodi produttivi di nuova generazione senza dipendere da terze parti.

I chip interessati da questa strategia sono molteplici:

• Tensor SoC — i processori custom dei Pixel
• TPU — le unità di elaborazione AI usate nei data center
• Futuri acceleratori AI proprietari

Cosa cambierebbe per i dispositivi Pixel

Un accesso privilegiato a TSMC significherebbe per Google poter integrare nei Pixel i processi produttivi più recenti con largo anticipo rispetto alla concorrenza Android, riducendo il gap prestazionale con Apple Silicon. I chip Tensor sono già realizzati su processo TSMC, ma la relazione indiretta limita il margine di manovra di Google in termini di roadmap e capacità produttiva.

Si tratta ancora di indiscrezioni, ma la direzione è chiara: Google vuole costruire una filiera hardware sempre più autonoma e competitiva, sul modello di quanto Apple ha saputo fare nel corso degli ultimi quindici anni.

Wine è un progetto storico nato negli anni ’90 con l’obiettivo di permettere l’esecuzione di applicazioni e videogiochi sviluppati per Microsoft Windows all’interno di sistemi operativi come GNU/Linux, macOS e, in parte, anche BSD. A differenza di un emulatore tradizionale, Wine non ricrea...

🔗 Leggi il post completo

I requisiti per accedere a Gemini Intelligence — la nuova piattaforma AI on-device di Google per Android — si stanno rivelando molto più stringenti del previsto. A rischio di esclusione non ci sono solo i dispositivi di fascia media, ma anche alcuni flagship come Xperia 1 VIII di Sony e persino alcuni modelli della linea Google Pixel.

I requisiti ufficiali di Gemini Intelligence

Gemini Intelligence è progettato per funzionare a livello di sistema operativo, non come semplice app. I requisiti noti includono:

• Gemini Nano v3 o superiore (AI on-device integrata nell’OS)
• Chipset di livello flagship
• Almeno 12 GB di RAM
• Criteri di qualità elevati (crash rate, stabilità)
• Capacità avanzate per HDR, audio spaziale e visione notturna
• Garanzia di almeno 5 aggiornamenti OS
• Supporto a tecnologie di sicurezza e virtualizzazione (AVF)

Xperia 1 VIII e il problema degli aggiornamenti OS

Nel caso di Sony, il problema non sembra essere legato all’hardware — Xperia 1 VIII è tecnicamente un flagship potente — ma alla politica di aggiornamenti software. Sony garantisce meno aggiornamenti OS rispetto ai 5 richiesti da Google, il che potrebbe renderla incompatibile con Gemini Intelligence anche a prescindere dalle specifiche tecniche.

Una situazione che apre un dibattito più ampio sulla necessità per i produttori Android di impegnarsi su aggiornamenti a lungo termine se vogliono garantire ai propri utenti accesso alle funzionalità AI più avanzate. Google, con questa mossa, lancia un segnale chiaro all’intero ecosistema Android.

Xiaomi si prepara a lanciare un nuovo modello di auricolari wireless con un design insolito e funzionalità di fascia alta. Si tratta di un modello ear-cuff — cioè con clip sull’orecchio anziché inserimento nel padiglione auricolare — pensato per chi cerca comfort durante l’uso prolungato. Il lancio è atteso in concomitanza con lo Xiaomi 17 Max.

Design leggero e indossabilità al primo posto

Il peso di soli 5,5 grammi per auricolare è uno dei punti di forza dichiarati da Xiaomi. La struttura è stata progettata con ergonomia e materiali flessibili, tra cui un filo in titanio con memoria di forma che si adatta alla forma dell’orecchio. Il design open-ear, che non chiude il condotto uditivo, garantisce una percezione dell’ambiente circostante e riduce l’affaticamento da uso prolungato.

LHDC 5.0 e riduzione del rumore per le chiamate tramite AI

Sul fronte audio, Xiaomi punta sulla tecnologia LHDC 5.0, che permette una trasmissione wireless ad alta risoluzione con bitrate superiori rispetto al classico aptX o SBC. Per chi usa gli auricolari anche per telefonate, c’è la riduzione del rumore AI durante le chiamate, in grado di isolare la voce dell’utente dal rumore di fondo.

Xiaomi non ha ancora comunicato il prezzo ufficiale né tutti i dettagli tecnici, ma il lancio imminente insieme allo Xiaomi 17 Max fa intuire che il posizionamento sarà nel segmento premium degli accessori audio del brand. Ulteriori dettagli saranno svelati nelle prossime settimane.

Google ha avviato il rilascio di una nuova versione di Quick Share che permette di condividere file tra Android e iPhone senza installare alcuna app. La funzionalità, da sempre apprezzata per la semplicità di trasferimento tra dispositivi Android, si apre ora al mondo iOS grazie a un sistema basato su QR code.

Come funziona la condivisione cross-platform

Il meccanismo è semplice e non richiede configurazioni particolari. Dal dispositivo Android, si avvia Quick Share normalmente: l’app genera un QR code univoco associato al trasferimento. L’utente iPhone deve solo inquadrare il codice con la fotocamera del proprio dispositivo — nessuna app da scaricare, nessun account da creare.

Una volta letto il QR, il file viene caricato in modo sicuro dal dispositivo Android al cloud, per poi essere scaricato sull’iPhone del destinatario. Google ha precisato che il trasferimento è cifrato end-to-end e che il link condiviso rimane valido per un massimo di 24 ore.

Un passo importante per l’interoperabilità mobile

Questa novità rappresenta un significativo passo in avanti nella direzione di un ecosistema mobile più aperto, dove la condivisione di file tra sistemi operativi diversi non richiede soluzioni di terze parti come WeTransfer o AirDrop limitato all’ecosistema Apple.

Quick Share era già disponibile su Windows attraverso un’app dedicata, ma l’estensione nativa verso iOS — senza richiedere l’installazione di nulla sull’iPhone — è decisamente la mossa più importante finora. Il rollout è già in corso e dovrebbe raggiungere tutti gli utenti nelle prossime settimane.

Google ha fornito chiarimenti ufficiali riguardo a una modifica che ha generato preoccupazione tra gli utenti: alcuni nuovi account Gmail stanno ricevendo solo 5 GB di spazio di archiviazione gratuito, anziché i classici 15 GB. Il colosso di Mountain View ha confermato che si tratta di un test limitato, con obiettivi ben precisi che vanno oltre la semplice riduzione dello spazio.

Un esperimento su nuovi account in alcune regioni

In risposta alle segnalazioni degli utenti, Google ha dichiarato ad Android Authority di stare conducendo un test su nuovi account creati in alcune aree geografiche. L’azienda ha specificato che l’iniziativa mira a:

• Mantenere la qualità del servizio su larga scala
• Rafforzare la sicurezza degli account
• Migliorare i sistemi di recupero dati

Non si tratterebbe quindi di una semplice riduzione dello spazio, ma di un’operazione sperimentale più ampia che include anche aspetti di gestione e infrastruttura. Le regioni coinvolte non sono state specificate, sebbene le segnalazioni provengano principalmente dall’Africa.

Gli utenti esistenti non sono coinvolti

Google ha rassicurato gli utenti già registrati: chi possiede un account Gmail esistente non vedrà modifiche ai propri 15 GB gratuiti. Il test riguarda esclusivamente i nuovi account creati durante il periodo di sperimentazione in specifiche aree geografiche.

Per ora non è chiaro se e quando questa nuova policy potrebbe essere estesa più ampiamente o diventare definitiva. Google non ha fornito una tempistica precisa, lasciando aperta la questione su quale sarà il futuro dello spazio gratuito offerto con i nuovi account Gmail.

Samsung potrebbe confermare ancora una volta la sua preferenza per i chip MediaTek nei tablet di fascia alta. Secondo le ultime informazioni emerse dall’analisi del codice dell’app AI Core di Samsung, il prossimo Galaxy Tab S12 potrebbe montare il nuovo Dimensity 9500 di MediaTek, abbandonando definitivamente l’ipotesi Snapdragon per i tablet del produttore coreano.

Dimensity 9500 trovato nel codice di Samsung AI Core

La scoperta è stata possibile grazie all’analisi del codice interno dell’applicazione AI Core di Samsung, dove è apparsa la sigla MT6993 — identificatore corrispondente al chip Dimensity 9500 di MediaTek. Pur non essendoci un riferimento esplicito al Galaxy Tab S12, il contesto suggerisce fortemente che si tratti di configurazioni destinate a nuovi dispositivi in arrivo.

Samsung ha già adottato chip MediaTek sui Galaxy Tab S10 e S11, e stando a queste nuove informazioni la tendenza sembra destinata a proseguire anche con la prossima generazione. Una scelta che potrebbe sorprendere chi sperava in un ritorno a Snapdragon per i tablet premium del brand.

AI e funzionalità avanzate al centro della nuova architettura

Nel codice analizzato emergono anche riferimenti a funzionalità legate all’intelligenza artificiale, il che suggerisce che Samsung stia ottimizzando le sue app AI per sfruttare appieno le capacità del nuovo chip MediaTek. Il Dimensity 9500 è progettato con un forte focus sull’elaborazione AI on-device, caratteristica che si allinea perfettamente con la direzione intrapresa da Samsung nel campo degli assistenti intelligenti integrati.

Resta da vedere se questa strategia si rivelerà vincente agli occhi dei consumatori, considerando che Snapdragon rimane il punto di riferimento nel segmento premium. Per ora, i fan di Samsung dovranno attendere l’annuncio ufficiale per scoprire tutti i dettagli del Galaxy Tab S12.

Cos’è Microsoft DSC v3 e perché è importante

Microsoft Desired State Configuration (DSC) è uno strumento di gestione della configurazione che permette di descrivere come deve essere configurato un sistema Windows o Linux — quali servizi devono essere in esecuzione, quali regole firewall applicare, quali funzionalità installare — e di applicare o verificare automaticamente quella configurazione. Con DSC v3, Microsoft ha riscritto l’engine da zero rispetto alla versione 2.x integrata in PowerShell, separando nettamente il motore DSC dai moduli PowerShell e aprendo la strada al supporto multi-piattaforma e multi-linguaggio.

Il 29 aprile 2026, il team PowerShell ha annunciato la General Availability di DSC v3.2.0. Questa release porta con sé risorse Windows native, l’integrazione sperimentale con Bicep via gRPC, il version pinning, un linguaggio di espressioni più ricco e miglioramenti agli adapter PowerShell. Vediamo in dettaglio cosa cambia per i sistemisti e gli amministratori di sistema che adottano DSC nei loro ambienti.

Come installare DSC v3.2.0

La modalità di installazione più semplice è tramite WinGet:

winget install --id Microsoft.DSC --version 3.2.0

Nuove risorse Windows built-in

Una delle novità più attese di DSC v3.2.0 è l’espansione significativa delle risorse Windows native, ovvero risorse incluse direttamente nel pacchetto DSC e utilizzabili senza installazioni aggiuntive.

Le nuove risorse disponibili sono le seguenti:

• Microsoft.Windows/Service — gestione dei servizi Windows (stato, tipo di avvio, account di esecuzione)
• Microsoft.Windows/OptionalFeatureList — gestione delle funzionalità opzionali di Windows
• Microsoft.Windows/FeatureOnDemandList — gestione delle Features on Demand (FoD)
• Microsoft.Windows/FirewallRuleList — gestione delle regole del Windows Firewall
• Microsoft.OpenSSH.SSHD/sshd_config — gestione dell’intera configurazione del server SSH
• Microsoft.OpenSSH.SSHD/Subsystem e SubsystemList — gestione dei sottosistemi SSH
• Microsoft.OpenSSH.SSHD/Windows — configurazione Windows-specifica del server SSH (es. shell predefinita)

Un esempio pratico: per assicurarsi che il servizio Print Spooler sia disabilitato (pratica comune per ridurre la superficie d’attacco), basta ora scrivere:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
resources:
  - name: DisabilePrintSpooler
    type: Microsoft.Windows/Service
    properties:
      name: spooler
      startType: disabled
      state: stopped

Version pinning: configurazioni stabili e riproducibili

Una delle criticità di DSC v2 era la mancanza di un meccanismo affidabile per legare una configurazione a una specifica versione delle risorse. In ambienti enterprise con molti server e deployment automatizzati, una risorsa aggiornata poteva cambiare comportamento inaspettatamente.

DSC v3.2 risolve questo problema introducendo il version pinning sia a livello di documento di configurazione che a livello di singola risorsa. È possibile fissare la versione di DSC richiesta con la direttiva version e la versione di ogni risorsa con il campo requireVersion, usando la stessa sintassi semantica di npm/nuget:

$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
directives:
  version: '=3.2.0'          # Questa configurazione richiede esattamente DSC 3.2.0
resources:
  - name: os
    type: Microsoft/OSInfo
    requireVersion: '^1.0'   # Versioni >= 1.0.0 e =1.0.0, 

Supporto –what-if sulle singole risorse

Il flag --what-if esiste già da versioni precedenti per il comando dsc config set, ma era limitato all’esecuzione dell’intera configurazione. Con DSC v3.2, l’operazione di preview è disponibile anche sul comando dsc resource set, permettendo di testare il comportamento di una singola risorsa prima di applicarla:

dsc resource set --what-if \
  --resource Microsoft.Windows/Service \
  --input '{ "name": "spooler", "startType": "disabled" }'

Integrazione sperimentale con Bicep via gRPC

La novità più ambiziosa di questa release è l’introduzione di un server gRPC in DSC, che permette a Bicep di orchestrare direttamente le risorse DSC senza passare per Azure Resource Manager (ARM). L’estensione dsc-bicep-ext è ora inclusa nel pacchetto MSIX e disponibile nel PATH di sistema.

In pratica, questo significa che sarà possibile scrivere configurazioni DSC nella sintassi Bicep, sfruttando il tooling e le funzionalità del linguaggio (modularità, parametri tipizzati, linting) per gestire la configurazione di sistema. L’integrazione è attualmente marcata come sperimentale, ma rappresenta una direzione strategica importante: avvicinare la gestione della configurazione di sistema agli strumenti Infrastructure-as-Code già adottati dagli ambienti Azure.

Miglioramenti al linguaggio di espressione

I documenti di configurazione DSC v3.2 supportano ora un linguaggio di espressione più ricco, che riprende in parte la sintassi ARM/Bicep:

• Lambda expressions con le funzioni map() e filter()
• Funzioni dataUri() e dataUriToString() per la gestione di contenuti encodati
• Utilizzo di reference() all’interno di loop copy
• secret() per il recupero di segreti a runtime tramite estensioni dedicate

Il campo requireVersion sostituisce il precedente apiVersion per specificare i requisiti di versione, uniformando la sintassi con i nuovi meccanismi di pinning.

Adapter PowerShell: trace automatica e manifest adattati

Per chi utilizza risorse PowerShell esistenti tramite gli adapter PSDSC, DSC v3.2 porta alcune novità significative. È stata aggiunta la conversione automatica degli stream PowerShell (Write-Verbose, Write-Warning, ecc.) in trace DSC, il che significa che le risorse esistenti partecipano automaticamente al modello di tracing senza modifiche al codice.

È stato inoltre corretto il passaggio di credenziali alle istanze di risorse PSDSC adattate, un bug che causava problemi in ambienti con configurazioni di sicurezza elevate.

Conclusione

DSC v3.2.0 consolida la piattaforma DSC v3 con funzionalità concrete e richieste dalla community: risorse Windows native, version pinning per deployment riproducibili, preview granulare con --what-if e l’avvio di un’integrazione Bicep che promette di semplificare notevolmente la gestione IaC negli ambienti Microsoft.

Per chi gestisce ambienti Windows Server, Intune o pipeline DevOps su infrastruttura Microsoft, vale la pena iniziare a esplorare DSC v3.2 e valutare la migrazione dalle configurazioni DSC v2, la cui architettura è ormai considerata legacy.

Fonte: Announcing Microsoft Desired State Configuration v3.2.0 – PowerShell Team Blog

Quanto tempo impiegano davvero gli smartphone più diffusi a ricaricarsi? CNET ha risposto a questa domanda con un test su 33 dispositivi, scoprendo che Galaxy S26 Ultra e iPhone 17 Pro dominano rispettivamente la ricarica via cavo e quella wireless, ma con dinamiche molto più articolate di quanto si possa immaginare guardando solo i watt dichiarati.

La metodologia del test

Il test è stato condotto su 33 smartphone di Apple, Samsung, Google, OnePlus, Motorola e altri brand. La metodologia simula un utilizzo reale: partendo da una batteria sotto il 10%, ogni dispositivo viene collegato al caricabatterie per 30 minuti — sia via cavo che in wireless — e si misura la percentuale di carica recuperata. Il punteggio finale è una media dei due risultati, così da premiare chi eccelle in entrambe le modalità.

Ricarica via cavo: Galaxy S26 Ultra in testa

Nella classifica pura della ricarica cablata, Galaxy S26 Ultra si aggiudica il primo posto raggiungendo circa il 76% di carica in 30 minuti, grazie all’implementazione da 60W della tecnologia Samsung. iPhone 17 Pro insegue con il 74%, una differenza minima ma sufficiente a cedere il primato. Il margine stretto testimonia quanto la competizione in questo segmento si sia intensificata.

Ricarica wireless: Apple domina con MagSafe

Sul fronte wireless la situazione si ribalta completamente: iPhone 17 Pro raggiunge il 55% di carica in 30 minuti, piazzandosi al primo posto davanti agli altri modelli iPhone che occupano le posizioni subito seguenti. Lo standard Qi2.2 e il sistema MagSafe garantiscono un allineamento preciso e una trasmissione efficiente dell’energia, compensando le caratteristiche fisiche del dispositivo. I dispositivi Android mostrano ancora un certo ritardo in questo specifico ambito.

Watt in più non significa sempre più veloce

Il risultato più interessante del test è la conferma che la velocità di ricarica dipende da una combinazione di fattori: capienza della batteria, efficienza del chip, tecnologia delle celle (silicio-carbonio vs litio convenzionale) e standard di carica supportati. Alcuni dispositivi con uscita dichiarata elevata si sono rivelati più lenti di quanto ci si aspettasse, mentre modelli con watt nominalmente inferiori hanno recuperato percentuali maggiori. Per gli utenti Android, la ricarica ultra-rapida via cavo rimane un punto di forza rispetto a Apple, mentre il gap nel wireless si sta lentamente riducendo con la diffusione di Qi2.

C’è ancora un mercato per gli smartphone con tastiera fisica? A giudicare dal successo del crowdfunding di Titan 2 Elite di Unihertz, la risposta è sì. Il dispositivo, che richiama i fasti dei BlackBerry degli anni 2000, ha raccolto oltre 4 milioni di dollari in 50 giorni di campagna e ha ora aperto le prenotazioni al grande pubblico.

Crowdfunding da record per un’idea retrò

Unihertz ha concluso la campagna di crowdfunding per Titan 2 Elite e Titan 2 Elite Pro con risultati sorprendenti: più di 8.500 sostenitori e oltre 4 milioni di dollari raccolti in 50 giorni. Un successo che testimonia come la nostalgia per la tastiera fisica — e le sue innegabili caratteristiche ergonomiche per la digitazione — non sia affatto scomparsa tra gli utenti di smartphone.

La spedizione ai sostenitori del crowdfunding è prevista a partire da giugno 2026, ma chi non ha partecipato alla campagna può già prenotare il dispositivo attraverso il sito ufficiale di Unihertz.

Prezzi e modelli disponibili

Il passaggio dalla fase crowdfunding alla vendita generale ha comportato un aumento dei prezzi. Titan 2 Elite è ora proposto a 489,99 dollari, contro i 349,99 del finanziamento iniziale. Titan 2 Elite Pro, la versione superiore con storage raddoppiato, prestazioni migliorate e fotocamera con stabilizzazione ottica, costa 579,99 dollari. Entrambi i modelli sono disponibili in nero e arancione.

Tempi di spedizione differenziati

I tempi di attesa variano in base al modello scelto: Titan 2 Elite inizierà le spedizioni in agosto 2026, mentre chi opta per il modello Pro dovrà attendere fino a dicembre 2026. Una finestra temporale piuttosto ampia che potrebbe scoraggiare i meno pazienti, ma che riflette la complessità produttiva di un dispositivo con hardware così particolare. In un mercato dominato da smartphone sempre più simili tra loro, Titan 2 Elite punta decisamente sulla differenziazione.

Xiaomi ha ufficialmente anticipato il suo primo auricolare wireless di tipo clip-on, ovvero ad aggancio sull’orecchio senza inserimento nel canale uditivo. Il teaser pubblicato mostra un design radicalmente diverso rispetto agli auricolari Xiaomi Buds tradizionali, con un’estetica futuristica che strizza l’occhio al segmento open-ear di fascia premium.

Un design tutto nuovo

Le immagini teaser mostrano un prodotto dal look molto distintivo: finitura a specchio lucida, corpo in un unico pezzo senza giunture visibili e una sfera trasparente come elemento caratterizzante. Il meccanismo di fissaggio è di tipo clip a forma di C, che abbraccia il padiglione auricolare dall’esterno senza entrare nel condotto uditivo. Questo sistema — già adottato da Huawei FreeClip e Bose Ultra Open Earbuds — permette di ascoltare musica pur restando pienamente consapevoli dell’ambiente circostante.

Case con speaker integrato

Dai documenti tecnici trapelati sui social cinesi emergono dettagli interessanti sull’astuccio di ricarica. Oltre alla porta USB-C, al LED indicatore e al pulsante di accensione fisico, la custodia ospiterebbe anche uno speaker integrato. Questa funzionalità servirebbe per emettere un segnale sonoro in caso di smarrimento, in sinergia con la funzione «Trova dispositivo» dello smartphone abbinato. Una soluzione pratica considerando quanto spesso i piccoli accessori wireless finiscano persi.

Area di controllo touch allargata

Le specifiche preliminari indicano che i sensori touch non saranno limitati alle estremità dell’auricolare, ma si estenderanno anche alla zona centrale del ponticello. Questo dovrebbe tradursi in un’area di controllo più ampia e meno soggetta a errori di comando, particolarmente utile durante l’attività fisica quando si indossano guanti o le mani sono in movimento.

Il mercato open-ear cresce rapidamente

Il segmento degli auricolari open-ear è in rapida espansione, trainato dalla preferenza di molti utenti per soluzioni che non isolano dall’ambiente esterno — ideali per uso urbano, sport all’aperto o lunghe sessioni di lavoro. L’ingresso di Xiaomi in questa categoria consolida ulteriormente l’ecosistema HyperOS e amplia l’offerta wearable del brand cinese. Il lancio è atteso nel corso del mese corrente.

Google sta sviluppando una nuova funzionalità per i Pixel 10 chiamata «Contextual Suggestions» (suggerimenti contestuali), un sistema di intelligenza artificiale che apprende le abitudini quotidiane dell’utente per proporre azioni pertinenti nel momento più opportuno. La funzione rappresenta un ulteriore passo verso lo smartphone come assistente personale proattivo.

Come funziona Contextual Suggestions

Il sistema analizza i comportamenti abituali dell’utente — routine giornaliere, posizione geografica, app utilizzate in determinati orari — e genera suggerimenti pertinenti prima ancora che l’utente sappia di averne bisogno. Tra gli esempi pratici documentati ci sono la proposta di riprodurre la playlist preferita quando ci si dirige in palestra, oppure il suggerimento di attivare il cast di una partita della squadra del cuore quando lo smartphone riconosce che si è soliti guardare le partite in televisione in quella fascia oraria.

On-device AI per la privacy

Un aspetto fondamentale di Contextual Suggestions è che l’elaborazione avviene interamente sul dispositivo, senza inviare dati comportamentali al cloud. Google sottolinea che le informazioni raccolte non vengono condivise con app di terze parti, né con i server Google stessi. Questo approccio on-device potrebbe rendere la funzione esclusiva dei Pixel 10, che dispongono del chip Tensor ottimizzato per questo tipo di elaborazione locale.

Dove si attiva e come si configura

La funzionalità è stata individuata nelle impostazioni di sistema, sotto il percorso Servizi Google → Tutti i servizi → Altro. Sembra che sia abilitata per impostazione predefinita, anche se gli utenti potranno disattivarla a piacere. È stata segnalata su alcuni dispositivi Pixel 10 e Pixel 10a con Android 16 e la versione più recente dei Google Play Services.

L’evoluzione AI dei Pixel continua

Contextual Suggestions si inserisce in un percorso ben definito per la linea Pixel: negli ultimi anni Google ha introdotto funzioni come la risposta automatica alle chiamate, la sbobinatura in tempo reale, la gomma magica e il riassunto di conversazioni, tutte basate su AI locale. Con questo nuovo strumento, l’obiettivo è trasformare il Pixel 10 in un assistente che anticipa le necessità anziché limitarsi a rispondere ai comandi. Non sono ancora stati comunicati tempi di rilascio ufficiali per la disponibilità generale.

Google starebbe testando una modifica significativa alla politica di storage gratuito per gli account Gmail: alcuni utenti che hanno creato un nuovo account di recente si sono visti assegnare solo 5GB di spazio invece dei consueti 15GB, con la possibilità di sbloccare i restanti 10GB solo registrando un numero di telefono. La notizia ha scatenato un acceso dibattito online.

Il meccanismo segnalato dagli utenti

La scoperta è emersa su Reddit, dove diversi utenti hanno condiviso screenshot che mostrano chiaramente il nuovo flusso di onboarding. Al momento della creazione dell’account, Google indicherebbe 5GB come capienza di partenza, specificando che l’aggiunta di un numero di telefono verificato permette di accedere alla quota standard di 15GB. Si ricorda che questo spazio è condiviso tra Gmail, Google Drive e Google Foto: una riduzione a 5GB avrebbe quindi un impatto molto concreto sull’utilizzo quotidiano di tutti e tre i servizi.

Antispam o raccolta dati?

Le interpretazioni della mossa di Google si dividono nettamente. Una parte degli utenti vede in questa modifica un tentativo di ridurre la proliferazione di account usa-e-getta e di contrastare lo spam generato automaticamente da bot, problema diventato ancora più acuto con la diffusione degli strumenti di AI generativa. Un’altra parte, invece, interpreta la richiesta del numero di telefono come una strategia per raccogliere più dati personali identificativi degli utenti.

Test limitato, non ancora ufficiale

È importante sottolineare che, al momento, la pagina ufficiale di supporto Google indica ancora 15GB come quota gratuita standard. Alcuni utenti in fase di test vedono ancora la vecchia schermata, il che suggerisce che si tratti di un A/B test condotto su un sottoinsieme di nuovi iscritti. Anche la disponibilità geografica del test sembra variabile. Fino a un’eventuale annuncio ufficiale da parte di Google, non si può considerare questa una modifica definitiva alla politica di archiviazione.

La direzione di Google verso account più verificati

Indipendentemente dall’esito di questo specifico test, la tendenza di Google verso una maggiore verifica dell’identità degli account è evidente da tempo. L’autenticazione a due fattori è già spinta attivamente, e la richiesta di un numero di telefono in fase di registrazione è ormai semi-obbligatoria in molte configurazioni. Condizionare la quota di storage alla verifica telefonica rappresenterebbe il passo successivo in questa direzione, con conseguenze notevoli per chi preferisce mantenere un profilo di privacy elevato nei confronti dei grandi servizi cloud.

Xiaomi starebbe per alzare il sipario su due nuovi smartphone: 17T e 17T Pro. Secondo informazioni trapelate da fonti accreditate nel settore, la presentazione globale è attesa per il 28 maggio 2026. In parallelo, emergono voci su una possibile espansione internazionale anche di Xiaomi 17 Max, con l’India indicata come primo mercato di riferimento.

L’evento del 28 maggio

Il leaker Yogesh Brar ha condiviso su X la notizia di un evento Xiaomi fissato per il 28 maggio, dedicato al lancio globale della serie 17T. I dispositivi erano già apparsi in database benchmark nelle scorse settimane, confermando che lo sviluppo del prodotto è in fase avanzata. Non sono ancora noti i mercati specifici interessati dall’annuncio, ma Europa e Asia sembrano le destinazioni più probabili per la prima disponibilità.

Specifiche attese per Xiaomi 17T

Per il modello standard Xiaomi 17T si parla di un display AMOLED da 6,59 pollici con risoluzione 1.5K e refresh rate a 120Hz, mosso dal chipset MediaTek Dimensity 8500-Ultra. La configurazione di memoria prevista è 12GB di RAM con storage fino a 512GB. Sul fronte fotografico, la tripla fotocamera dovrebbe includere un sensore principale da 50MP, teleobiettivo da 50MP e ultra-grandangolare da 12MP, con frontale da 32MP. La batteria, da 6.500mAh, rappresenta uno dei punti di forza del dispositivo.

Xiaomi 17T Pro punta ancora più in alto

La variante Pro alza ulteriormente l’asticella con un pannello OLED da 6,83 pollici a 144Hz e il potente SoC Dimensity 9500. Il sensore principale dovrebbe montare il chip fotografico «Light Fusion 950», mentre la capienza della batteria salirebbe a circa 7.000mAh. Entrambi i modelli si candidano a essere tra i protagonisti della fascia premium-media nella seconda metà del 2026.

Anche il 17 Max potrebbe uscire dalla Cina

La stessa fonte segnala che sono in corso trattative per portare Xiaomi 17 Max nei mercati globali, India in testa. Si tratta del top di gamma assoluto di Xiaomi, con fotocamera Leica da 200MP e batteria da 8.000mAh, finora annunciato come esclusiva cinese. Se le indiscrezioni venissero confermate, si tratterebbe di un lancio di grande impatto per il mercato degli smartphone premium. Per quanto riguarda i prezzi globali, i leak parlano di circa 880 dollari per 17T e 1.170 dollari per 17T Pro.

Xiaomi ha intensificato la comunicazione attorno al prossimo 17 Max, il suo smartphone di punta che si appresta a stabilire nuovi record in ambito fotografico. La novità più sorprendente? Una fotocamera principale da 200 megapixel sviluppata in collaborazione con Leica, capace di produrre singoli scatti che superano i 100MB di dimensione.

200MP con sensore da 1/1.4 pollici

Xiaomi 17 Max monterà un sensore principale da 1/1.4 pollici con risoluzione di 200 megapixel, abbinato a un teleobiettivo periscopico 3x. Il sistema fotografico è progettato con l’apporto diretto di Leica, a conferma della partnership stretta avviata negli scorsi anni. Il sensore supporta un algoritmo di fusione multi-frame che combina più scatti per migliorare il range dinamico, le prestazioni in condizioni di bassa luminosità e la riduzione del rumore digitale.

Un’intera scena compressa in un solo file

Il presidente di Xiaomi Lu Weibing ha rivelato un dettaglio affascinante: le tre immagini di esempio pubblicate ufficialmente non sono tre foto distinte, ma tre ritagli estratti da un unico scatto originale da 200MP. Il file originale pesa circa 114,97MB, mentre i crop mostrano dimensioni rispettive di 10,29MB e 31,86MB. Questo dimostra la capacità del sensore di catturare una quantità di informazioni così elevata da permettere ritagli estremi senza perdita di qualità apprezzabile — una caratteristica molto utile per chi ama ricomporre la scena in post-produzione o condividere porzioni diverse dello stesso momento.

Estetica Leica e rendering cinematografico

Le immagini di esempio mostrano la tipica firma cromatica di Leica: colori sobri, contrasti definiti, tonalità naturali senza l’elaborazione aggressiva tipica di altri produttori. Sony mette in evidenza la resa delle texture su superfici come pietra e pavimentazione, la gestione delle alte luci in pieno sole e la separazione soggetto-sfondo. Il tutto con un tocco cinematografico nelle luci e nelle ombre che distingue il 17 Max dall’approccio “social-ready” di molti concorrenti.

Snapdragon 8 Elite di quinta generazione e batteria da 8.000mAh

Al di là delle fotocamere, Xiaomi 17 Max si presenta come una potenza assoluta: SoC Snapdragon 8 Elite di quinta generazione, display da 6,9 pollici in risoluzione 2K con cornici ultra-sottili, e una batteria da 8.000mAh che sarebbe la più capiente mai montata su un flagship Xiaomi. Il dispositivo dovrebbe rimanere un’esclusiva per il mercato cinese, almeno in questa prima fase di lancio.

scrcpy è un software libero sviluppato da Genymobile che consente di visualizzare e controllare un dispositivo Android direttamente dal computer, utilizzando un collegamento USB oppure la rete locale. scrcpy non richiede l’installazione permanente di...

🔗 Leggi il post completo

Xiaomi ha ufficialmente confermato le intenzioni di espandere la serie Redmi Turbo 5 al di fuori della Cina. Il primo mercato ad accogliere il dispositivo sarà l’India, dove l’account ufficiale Redmi India ha già pubblicato un teaser con la dicitura «Coming Soon» e dove Amazon India ha predisposto una pagina di prodotto dedicata.

Dall’esclusiva cinese al mercato globale

Fino ad oggi, Redmi Turbo 5 e la versione superiore Redmi Turbo 5 Max erano stati commercializzati esclusivamente in Cina. La decisione di portare almeno il modello base in India rappresenta un cambio di strategia per Xiaomi, che punta a rafforzare la propria presenza nella fascia sub-flagship del subcontinente indiano, un mercato estremamente competitivo e ricco di potenziale.

Non è ancora stata comunicata una data ufficiale di lancio, ma i segnali provenienti dalla catena distributiva suggeriscono che le vendite potrebbero partire prima della fine di giugno. Al momento, l’espansione sembra limitata all’India, senza conferme per altri mercati internazionali.

Il rapporto con Poco X8 Pro

Un elemento di interesse strategico riguarda la sovrapposizione con l’ecosistema Poco, altro sub-brand di Xiaomi. Poco X8 Pro e Poco X8 Pro Max sono già disponibili a livello globale e vengono considerati, in sostanza, le versioni internazionali di Redmi Turbo 5 e Turbo 5 Max. L’arrivo del Redmi Turbo 5 direttamente in India sotto il brand Redmi potrebbe quindi indicare un riposizionamento nella strategia multimarchio di Xiaomi nel paese.

Mercato indiano sempre più conteso

L’India è uno dei mercati smartphone più dinamici al mondo, con una crescente domanda di dispositivi sub-flagship che offrano prestazioni premium a prezzi accessibili. Xiaomi, con i brand Redmi, Poco e Mi, è già uno dei player dominanti in questo segmento. L’arrivo di Redmi Turbo 5 potrebbe intensificare ulteriormente la concorrenza con OnePlus Nord, Samsung Galaxy A-series e altri rivali diretti in quella fascia di prezzo.