Google just announced a new unifying identity for its Local Services Ads (LSAs) verification badges.

Called Google Verified, the badge will replace several different trust signals that advertisers and consumers have been seeing over the years.

This includes the Google Guaranteed, Google Screened, License Verified by Google, and the Money Back Guarantee program.

Starting in October 2025, eligible LSAs that pass the necessary screenings will display this streamlined mark: a single badge designed to communicate credibility in a more consistent way.

Why is Google Consolidating Badges?

In the past, Google’s verification system was fragmented.

Different types of businesses had different badges, and consumers were left guessing what each one actually meant. Was a “Screened” provider more trustworthy than a “Guaranteed” one? Did a license verification carry more weight than a money-back promise?

The lack of consistency made it harder for advertisers to explain their value and for consumers to make decisions.

By rolling everything into one identity, Google Verified aims to simplify the process for everyone involved.

The badge will not only appear across Local Service Ads but will also include transparency for consumers. When a user taps or hovers over the badge, they can see the specific checks a business has passed.

How Does This Change Impact Advertisers?

For marketers and business owners, the simplified badge system removes some of the confusion around what signals matter.

Instead of juggling multiple programs, the message is now clear: your business is either Google Verified, or it’s not.

That said, the bar for participation may feel higher. Businesses that don’t keep their documentation, licensing, and other requirements up to date risk losing the badge.

Since Google has indicated it may only show the badge when it predicts it will help users make decisions, credibility and visibility could become even more closely linked.

In short, advertisers who maintain verification stand to benefit from increased trust, while those who lag behind could see their ads appear less competitive.

This update doesn’t require marketers to overhaul their entire strategy by any means. However, there are a few practical steps you can take to ensure a smooth transition by October.

• Review eligibility now. Make sure your licenses, insurance, and background checks are up-to-date before October.
• Build in reminders. Treat verification like an ongoing compliance process, not a one-time task.
• Educate clients or internal teams. If you manage LSA campaigns for others, help them understand that the badge isn’t just a cosmetic update. It reflects ongoing credibility.
• Monitor performance post-launch. Once the new badge rolls out, watch for shifts in click-thru rate (CTR) and conversion rates. If verification gives a measurable lift, you’ll want to highlight that value in your reporting.

A Shift Toward Ongoing Trust

Google Verified may look like a rebrand on the surface, but it’s also a signal that trust in digital advertising is moving toward continuous validation.

For businesses, this means credibility is not something you earn once; it’s something you prove over and over again.

For advertisers, the key takeaway is simple: don’t treat this as a one-time update. Verification will become an expectation, not a nice-to-have, and it could influence not just how consumers view your ads but how often those ads are shown.

https://www.searchenginejournal.com/google-confirms-new-google-verified-badge-for-local-services-ads/554360/

Ago 21, 2025 Redazione Attacchi, In evidenza, News, RSS, Vulnerabilità 0

---

Un gruppo di cyber spionaggio legato ai servizi segreti russi sta sfruttando una falla di sicurezza risalente a sette anni fa nei software Cisco IOS e IOS XE. L’allarme arriva da Cisco Talos che ha osservato attività riconducibili a Static Tundra, un gruppo collegato all’FSB e operativo da oltre un decennio impegnato nella raccolta di intelligence a lungo termine.

Secondo i ricercatori, il gruppo prende di mira settori sensibili come telecomunicazioni, università e manifatturiero, con attacchi documentati in Nord America, Europa, Asia e Africa. Negli ultimi anni le attività si sono concentrate soprattutto contro l’Ucraina e i suoi alleati, in parallelo al conflitto avviato nel 2022.

Una vulnerabilità critica mai scomparsa

Il punto d’ingresso sfruttato dagli attaccanti è la CVE-2018-0171, una vulnerabilità critica (CVSS 9.8) nel protocollo Smart Install che può consentire a un aggressore remoto e non autenticato di provocare denial of service o eseguire codice arbitrario. Nonostante la patch sia disponibile dal 2018, molti dispositivi vulnerabili restano esposti, in particolare quelli obsoleti o non più supportati.

Lo stesso difetto era stato già sfruttato in passato da altri gruppi di hacker di stato: tra questi il gruppo cinese Salt Typhoon, che nel 2024 lo aveva utilizzato contro provider statunitensi.

Il Federal Bureau of Investigation (FBI) conferma in una nota che le operazioni di Static Tundra hanno coinvolto migliaia di apparati di rete negli Stati Uniti e a livello globale. Gli attaccanti avrebbero sfruttato anche SNMP e altri protocolli deboli per raccogliere file di configurazione, manipolare le impostazioni dei dispositivi e creare accessi non autorizzati.

Una volta stabilita la testa di ponte, i criminali conducono attività di ricognizione interna e installano tool personalizzati come SYNful Knock, un impianto malevolo sui router che modifica il firmware per mantenere persistenza e può essere aggiornato nel tempo. In alcuni casi, hanno utilizzato SNMP per scaricare file da server esterni e modificarne la configurazione oppure alterato i parametri TACACS+ per eludere i sistemi di logging.

Le operazioni mirano anche a intercettare traffico sensibile: gli attaccanti creano tunnel GRE per dirottare pacchetti verso infrastrutture controllate dal gruppo, oppure raccolgono dati NetFlow ed esfiltrano le informazioni tramite connessioni TFTP o FTP.

Target, finalità strategiche e contromisure

Static Tundra si concentra soprattutto su apparati non aggiornati o a fine vita, sfruttandoli come trampolino per spingersi più a fondo nelle reti delle vittime. L’obiettivo è ottenere informazioni di valore strategico e garantire un accesso a lungo termine, adattando le proprie operazioni agli interessi geopolitici russi del momento.

Cisco sottolinea che lo scopo della campagna è la raccolta massiva di configurazioni e dati di rete che possono essere sfruttati in tempi successivi in base alle priorità governative di Mosca.

L’azienda ha aggiornato il bollettino relativo alla CVE-2018-0171, ribadendo che la falla è tuttora sfruttata attivamente. La raccomandazione è di applicare senza ritardi le patch disponibili o, laddove non sia possibile aggiornare, disabilitare la funzione Smart Install.

---

• attacchi rete, Cisco IOS, Cisco IOS XE, Cisco Talos, CVE-2018-0171, cyber spionaggio Russia, FBI advisory, FSB, router compromessi, sicurezza informatica, Smart Install, spionaggio informatico, Static Tundra, SYNful Knock, vulnerabilità Cisco

---

---

https://www.securityinfo.it/2025/08/21/static-tundra-sfrutta-una-vecchia-vulnerabilita-cisco-per-spionaggio/?utm_source=rss&utm_medium=rss&utm_campaign=static-tundra-sfrutta-una-vecchia-vulnerabilita-cisco-per-spionaggio

Google is adding agentic booking features to AI Mode in Search, beginning with restaurant reservations for U.S. Google AI Ultra subscribers enrolled in Labs.

What’s New

Booking Reservations

AI Mode can interpret a detailed request, check real-time availability across reservation sites, and link you to the booking page to complete the task.

For businesses, that shifts more discovery and conversion activity inside Google’s surfaces.

Robby Stein wrote on The Keyword:

“We’re starting to roll out today with finding restaurant reservations, and expanding soon to local service appointments and event tickets.”

Planning Features

Google is introducing planning features that make results easier to share and tailor queries.

In the U.S., you can share an AI Mode response with others so they can ask follow-ups and continue research on their own, and you can revoke the link at any time.

Separately, U.S. users who opt in to the Labs experiment can receive personalized dining suggestions informed by prior conversations and interactions in Search and Maps, with controls in Google Account settings.

How It Works

Under the hood, Google cites live web browsing via Project Mariner, partner integrations, and signals from the Knowledge Graph and Maps.

Named partners include OpenTable, Resy, Tock, Ticketmaster, StubHub, SeatGeek, and Booksy. Dining is first; local services and ticketing are next on the roadmap.

Availability

Availability is gated. Agentic reservations are limited to Google AI Ultra subscribers in the U.S. through the “Agentic capabilities in AI Mode” Labs experiment.

Personalization is U.S. and opt-in, with dining topics first. Link sharing is available in the U.S. Global access to AI Mode is expanding to more than 180 countries and territories in English, with additional languages planned.

Looking Ahead

AI Mode is moving from answer generation to task completion.

If your category relies on reservation or ticketing partners, verify inventory accuracy, hours, and policies now, and make sure your structured data and Business Profile attributes are clean.

Track how bookings and referrals appear in analytics as Google widens coverage to more tasks and regions.

https://www.searchenginejournal.com/google-ai-mode-adds-agentic-booking-expands-to-more-countries/554345/

Patchstack published a case study that examined how well Cloudflare and other general firewall and malware solutions protected WordPress websites from common vulnerability threats and attack vectors. The research showed that while general solutions stopped threats like SQL injection or cross-site scripting, a dedicated WordPress security solution consistently stopped WordPress-specific exploits at a significantly higher rate.

WordPress Vulnerabilities

Due to the popularity of the WordPress platform, WordPress plugins and themes are a common focus for hackers, and vulnerabilities can quickly be exploited in the wild. Once proof-of-concept code is public, attackers often act within hours, leaving website owners little time to react.

This is why it is critical to be aware of the security provided by a web host and of how effective those solutions are in a WordPress environment.

Methodology

Patchstack explained their methodology:

“As a baseline, we have decided to host “honeypot” sites (sites against which we will perform controlled pentesting with a set of 11 WordPress-specific vulnerabilities) with 5 distinct hosting providers, some of which have ingrained features presuming to help with blocking WordPress vulnerabilities and/or overall security.

In addition to the hosting provider’s security measures and third-party providers for additional measures like robust WAFs or other patching providers, we have also installed Patchstack on every site, with our test question being:

• How many of these threats will bypass firewalls and other patching providers to ultimately reach Patchstack?
• And will Patchstack be able to block them all successfully?”

Testing process

Each website was set up the same way, with identical plugins, versions, and settings. Patchstack used a “exploitation testing toolkit” to run the same exploit tests in the same order on every site. Results were checked automatically and by hand to see if attacks were stopped, and whether the block came from the host’s defenses or from Patchstack.

General Overview: Hosting Providers Versus Vulnerabilities

The Patchstack case study tested five different configurations of security defenses, plus Patchstack.

1. Hosting Provider A Plus Cloudflare WAF

2. Hosting Provider B + Firewall + Monarx Server and Website Security

3. Hosting Provider C + Firewall + Imunify Web Server Security

4. Hosting Provider D + ConfigServer Firewall

5. Hosting Provider E + Firewall

The result of the testing showed that the various hosting infrastructure defenses failed to protect the majority of WordPress-specific threats, catching only 12.2% of the exploits. Patchstack caught 100% of all exploits.

Patchstack shared:

“2 out of the 5 hosts and their solutions failed to block any vulnerabilities at the network and server levels.

1 host blocked 1 vulnerability out of 11.

1 host blocked 2 vulnerabilities out of 11.

1 host blocked 4 vulnerabilities out of 11.”

Cloudflare And Other Solutions Failed

Solutions like Cloudflare WAF or bundled services such as Monarx or Imunify failed to consistently address WordPress specific vulnerabilities.

Cloudflare’s WAF stopped 4 of 11 exploits, Monarx blocked none, and Imunify did not prevent any WordPress-specific exploits. Firewalls such as ConfigServer, which are widely used in shared hosting environments, also failed every test.

These results show that while those kinds of products work reasonably well against broad attack types, they are not tuned to the specific security issues common to WordPress plugins and themes.

Patchstack is created to specifically stop WordPress plugin and theme vulnerabilities in real time. Instead of relying on static signatures or generic rules, it applies targeted mitigation through virtual patches as soon as vulnerabilities are disclosed, before attackers can act.

Virtual patches are mitigation for a specific WordPress vulnerability. This offers protection to users while a plugin or theme developer can create a patch for the flaw. This approach addresses WordPress flaws in a way hosting companies and generic tools can’t because they rarely match generic attack patterns, so they slip past traditional defenses and expose publishers to privilege escalation, authentication bypasses, and site takeovers.

Takeaways

• Standard hosting defenses fail against most WordPress plugin vulnerabilities (87.8% bypass rate).
• Many providers claiming “virtual patching” (like Monarx and Imunify) did not stop WordPress-specific exploits.
• Generic firewalls and WAFs caught some broad attacks (SQLi, XSS) but not WordPress-specific flaws tied to plugins and themes.
• Patchstack consistently blocked vulnerabilities in real time, filling the gap left by network and server defenses.
• WordPress’s plugin-heavy ecosystem makes it an especially attractive target for attackers, making effective vulnerability protection essential.

The case study by Patchstack shows that traditional hosting defenses and generic “virtual patching” solutions leave WordPress sites vulnerable, with nearly 88% of attacks bypassing firewalls and server-layer protections.

While providers like Cloudflare blocked some broad exploits, plugin-specific threats such as privilege escalation and authentication bypasses slipped through.

Patchstack was the only solution to consistently block these attacks in real time, giving site owners a dependable way to protect WordPress sites against the types of vulnerabilities that are most often targeted by attackers.

According to Patchstack:

“Don’t rely on generic defenses for WordPress. Patchstack is built to detect and block these threats in real-time, applying mitigation rules before attackers can exploit them.”

Read the results of the case study by Patchstack here.

Featured Image by Shutterstock/tavizta

https://www.searchenginejournal.com/common-hosting-defenses-ineffective-against-wordpress-threats/554320/

A vulnerability advisory was published for the Inspiro WordPress theme by WPZoom. The vulnerability arises due to a missing or incorrect security validation that enables an unauthenticated attacker to launch a Cross-Site Request Forgery (CSRF) attack.

Cross-Site Request Forgery (CSRF)

A CSRF vulnerability in the context of a WordPress site is an attack that relies on a user with admin privileges clicking a link, which in turn leverages that user’s credentials to execute a malicious action. The vulnerability has been assigned a CVSS threat rating of 8.1.

The advisory issued by Wordfence WordPress security company warned:

“This makes it possible for unauthenticated attackers to install plugins from the repository via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.”

The vulnerability affects Inspiro theme versions up to and including 2.1.2. Users are advised to update their theme to the latest version.

Featured Image by Shutterstock/Kazantseva Olga

https://www.searchenginejournal.com/inspiro-wordpress-theme-vulnerability-affects-over-70000-sites/554297/

Google quietly rolled out a change advertisers have wanted for years: site-level reporting for the Search Partner Network.

Until now, advertisers could only opt in or out, with little understanding of where their ads actually showed.

This update finally gives visibility into where budgets are spent outside of Google.

Google lists this as an August 2025 update in its Help Center, however it wasn’t announced widespread.

Read on to understand the update from Google, how advertisers are reacting, and what you can do with this new level of information.

What Changed in Search Partner Reporting?

The new reporting applies to Search, Shopping, and App campaigns. You’ll now see which partner sites served your ads and how many impressions each one received.

Think of it as the kind of placement data we already get in Performance Max, just extended to Search Partners.

This update follows other moves Google has made to address long-standing concerns about partner quality.

Earlier this year, they introduced brand safety pre-screening options with IAS, DoubleVerify, and Zefr. They also said parked domains will be opted out by default before the end of 2025.

This visibility layer feels like the missing piece that makes the rest of those updates more usable.

How Are Advertisers Reacting to This Update?

The update on Search Partner Network reporting was first found by Anthony Higman, who took to X (formerly Twitter) to share his opinion.

Higman stated:

Still Most Likely Wont Be Participating In The Search Partner Network But This Is Unprecedented And What ALL Advertisers Have Been Requesting For Decades! Honestly NEVER Thought I Would See This Day.”

Others gave some versioning mixture of applauding Google for giving data to advertisers that they’ve been asking for for years, while also being somewhat skeptical.

Mike Ryan replied to Higman with his thoughts:

I mean, good step but also, it’s the PMax version: impression data only.

Aaron Levy shared his thoughts on LinkedIn, stating that this is a major step in the right direction for Google.

Why This Matters & How to Take Action

Without Search Partner Network reporting, it was tough to justify opting in. Now advertisers finally have data to audit where ads run, decide if it fits brand standards, and see if partner traffic adds any real value.

That said, the update is only as good as the action that advertisers take with the information available.

Some sites won’t align with brand guidelines. Others may generate clicks but fail to drive quality conversions.

The difference is you can now point to actual data when making decisions, rather than relying on gut feel.

Here’s some quick pointers to make this update actionable:

• Run a quick placement audit. Pull the report and check for sites that don’t align with your brand. Exclude what’s clearly not a fit.
• Look beyond impressions. While this reporting is only limited to impressions, use your own conversion data to figure out which placements are driving useful traffic versus noise.
• Revisit opt-in of campaigns. Many advertisers avoided Search Partners altogether because of the black box. Now it may be worth testing again, but do it with defined guardrails and success metrics.
• Pressure test Smart Bidding. Google leans on Smart Bidding to balance Search Partner performance, but don’t assume it’s perfect. Keep an eye on conversion quality and modeled conversions before scaling.

Final Thoughts

If you’ve been skeptical of Search Partners, this update is a chance to take another look with data on your side.

If you’ve already been opted in, you finally have a way to prove which placements help your campaigns and which ones don’t.

Bottom line: advertisers now have a long overdue view into the Search Partner Network. With more visibility comes a bit more control, and smarter conversations about whether Search Partners deserve a place in your Search campaigns.

Will you be opting into Search Partner Network with this new reporting update?

https://www.searchenginejournal.com/google-quietly-announces-search-partner-network-placement-visibility/554294/

Ago 20, 2025 Giancarlo Calzetta In evidenza, News, Vulnerabilità 0

---

Il chatbot di assistenza clienti di Lenovo, chiamato Lena, è risultato esposto a una grave vulnerabilità che avrebbe permesso a un attaccante remoto di eseguire codice malevolo e sottrarre dati sensibili. La falla, individuata dai ricercatori di Cybernews e resa pubblica a inizio agosto, dimostra ancora una volta quanto i sistemi basati su intelligenza artificiale possano trasformarsi in un veicolo di rischio se non adeguatamente protetti.

L’attacco con un solo prompt

Il problema risiedeva nella gestione degli input forniti al chatbot. Attraverso un prompt appositamente costruito, lungo circa 400 caratteri, era possibile indurre Lena a restituire contenuti in formato HTML e JSON che includevano codice potenzialmente eseguibile dal browser della vittima. In questo modo, con un semplice comando, il sistema avrebbe inviato i cookie di sessione verso un server controllato dall’attaccante, consentendo di prendere il controllo delle conversazioni e di accedere a informazioni riservate.

Una volta ottenuti i cookie, gli aggressori avrebbero potuto muoversi liberamente nel portale di supporto, leggere dati personali, interagire con i sistemi e persino tentare installazioni di backdoor per mantenere un accesso persistente.

Il ruolo della scarsa validazione

Secondo l’analisi dei ricercatori, il cuore della vulnerabilità risiedeva nella mancanza di filtri adeguati su input e output del modello. Il chatbot non solo accettava comandi malevoli senza alcun controllo, ma li restituiva all’utente senza applicare procedure di sanificazione. L’assenza di regole di escaping e di restrizioni sull’esecuzione di codice lato client ha amplificato l’impatto della falla, trasformando un semplice prompt in un’arma capace di compromettere l’intero sistema di assistenza.

La vulnerabilità è stata scoperta e segnalata il 22 luglio 2025. Lenovo ha riconosciuto ufficialmente il problema il 6 agosto e, poco meno di due settimane più tardi, ha rilasciato una patch correttiva.

Con il diffondersi dei sistemi di AI, diventa sempre più impellente la creazione di un know how di sicurezza su questi sistemi che, per forza di cose, avrà bisogno di tempo per formarsi. Quello del prompt engineering è un settore ancora in rapida espansione, ma che bisogna tenere ben presente per evitare altri casi come questo.

---

---

---

https://www.securityinfo.it/2025/08/20/lenovo-il-chatbot-ai-lena-era-troppo-loquace/?utm_source=rss&utm_medium=rss&utm_campaign=lenovo-il-chatbot-ai-lena-era-troppo-loquace

Ago 19, 2025 Giancarlo Calzetta In evidenza, News, RSS, Scenario 0

---

Il team di sicurezza della Python Software Foundation, guidato da Mike Fiedler PyPI, ha introdotto un controllo automatico sui domini email scaduti per impedire il domain resurrection, una tecnica con cui gli attaccanti ricomprano un dominio lasciato scadere e lo usano per prendere il controllo degli account tramite il reset della password. Dall’inizio di giugno 2025 sono state invalidate oltre 1.800 caselle legate a domini in fase di scadenza, così da ridurre un vettore d’attacco subdolo che può portare attacchi molto difficili da identificare.

I domini scaduti sono un problema

Gli account PyPI, come molti quelli di molte altre piattaforme, sono legati a indirizzi email; gli indirizzi, a loro volta, dipendono da un nome di dominio che può scadere se non rinnovato. Quando ciò accade, chiunque può ricomprare quel dominio, configurare la posta e ricevere i link di recupero password per i progetti associati. Su pacchetti abbandonati ma ancora molto usati a valle, il rischio si amplifica: un takeover silenzioso può sostituire versioni legittime con release malevole, con impatti a catena su CI/CD e ambienti di produzione. Questo scenario non è puramente speculativo, purtroppo: nel 2022 il pacchetto ctx su PyPI fu compromesso proprio sfruttando un dominio scaduto del maintainer a cui seguì la pubblicazione di versioni trojanizzate.

Come funziona il nuovo controllo di PyPI

Per individuare tempestivamente i casi a rischio, PyPI interroga periodicamente lo stato dei domini associati agli account, facendo leva sullo Status API di Domainr (un servizio Fastly) per capire in quale fase del ciclo di vita si trovano. Quando un dominio entra in redemption o in altre fasi indicative della perdita di controllo da parte del legittimo titolare, PyPI marca l’indirizzo email come “non verificato” e non invia reset password a quell’indirizzo. Dopo un primo controllo massivo ad aprile 2025, il monitoraggio prosegue in modo ricorrente; il team indica una finestra operativa di 30 giorni per allineare le verifiche al tipico ciclo “grazia–redemption–pending delete” dei registrar.

Cosa cambia per gli utenti e per gli attaccanti

La misura non è un’arma risolutiva, ma alza significativamente l’asticella. Per un attore ostile, acquistare un dominio scaduto non basta più per pilotare la procedura di recupero credenziali: l’email collegata all’account viene disattivata come fattore di prova e l’operazione si interrompe. Il beneficio si estende anche ai progetti poco attivi, dove il maintainer potrebbe non accorgersi per tempo dell’avvenuta scadenza o di un takeover del dominio. Dall’inizio di giugno a oggi, la revoca della verifica a più di 1.800 indirizzi conferma che il fenomeno è molto ampio.

Il team PyPI ribadisce alcuni accorgimenti per i maintainer. Abilitare la 2FA rimane essenziale e, se l’account usa un solo indirizzo su dominio personalizzato, conviene aggiungerne un secondo su un grande provider come Gmail o Outlook, così da avere un canale alternativo che non è soggetto a scadenza di dominio. La raccomandazione si intreccia con i processi di account recovery: riutilizzare lo stesso indirizzo anche su altri servizi di verifica può facilitare prove di identità incrociate, ma solo se gli altri account sono a loro volta protetti da 2FA.

Un tassello in più nella difesa della filiera open source

Negli ultimi anni i software supply-chain attack hanno spesso fatto leva sugli anelli deboli degli ecosistemi di pacchetti, e l’account takeover dei maintainer è tra i metodi a maggior impatto con basso sforzo. Bloccare i reset password verso indirizzi su domini scaduti riduce la superficie d’attacco senza penalizzare gli utenti legittimi, e si affianca ad altre misure introdotte da PyPI, come l’obbligo di 2FA per gli account attivi dalla data di riferimento definita dal progetto. L’episodio di ctx ha mostrato come un singolo maintainer compromesso possa generare danni su larga scala; l’automazione annunciata questa settimana mira a intercettare il problema prima che il dominio cambi davvero mano.

Prospettive

Il controllo dei domini non copre tutti i casi, ad esempio trasferimenti legittimi senza scadenza o scenari in cui l’attaccante compromette direttamente la 2FA dell’utente. Resta quindi cruciale mantenere igiene delle identità, rotazione delle token di pubblicazione, segregazione delle chiavi CI/CD e monitoraggio delle release. Ma l’iniziativa di PyPI è un segnale importante: prevenire è meglio che ripulire dopo una compromissione, soprattutto quando l’attacco può propagarsi lungo tutta la filiera di sviluppo.

---

• 2FA, account takeover, ato, autenticazione a due fattori, best practice maintainer, domain resurrection, domini scaduti, email non verificate, fastly status api, furto account maintainer, gestione domini, malware nei pacchetti, pacchetti abbandonati, pending delete, psf, PyPI, Python Package Index, python software foundation, redemption period, repository pacchetti, reset password, sicurezza open source, sicurezza registri open source, sicurezza supply chain, supply chain attack, sviluppo software, verifica email

---

---

https://www.securityinfo.it/2025/08/19/pypi-blocca-i-domain-resurrection-disattivate-1-800-email/?utm_source=rss&utm_medium=rss&utm_campaign=pypi-blocca-i-domain-resurrection-disattivate-1-800-email

OpenAI is rolling out a new subscription tier called ChatGPT Go, a competitively priced version that will initially be available only to users in India. It features ten times higher message limits, ten times more image generations, and file uploads than the free tier.

ChatGPT Go

OpenAI is introducing a new low-cost subscription plan that will be available first in India. The cost of the new subscription tiere is 399 Rupees/month (GST included). That’s the equivalent of $4.57 USD/month.

The new tier includes everything in the Free plan plus:

• 10X higher message limits
• 10x more image generations
• 10x more file uploads
• Twice as much memory

According to Nick Turley of ChatGPT:

“All users in India will now see prices for subscriptions in Indian Rupees, and can now pay through UPI.”

OpenAI’s initial announcement shared availability details:

“Available on web, mobile (iOS & Android), and desktop (macOS & Windows).

ChatGPT Go is geo-restricted to India at launch, and is able to be subscribed to by credit card or UPI.”

Featured Image by Shutterstock/JarTee

https://www.searchenginejournal.com/openai-announces-low-cost-subscription-plan-chatgpt-go/554082/

Google says the new Trends API is opening to a “quite small” set of testers at first, with access expanding over time. The company formally announced the alpha at Search Central Live APAC.

On Bluesky, Google Search Advocate John Mueller tried to set expectations for SEO professionals, writing:

“The initial pilot is going to be quite small, the goal is to expand it over time… I wouldn’t expect the alpha/beta to be a big SEO event :)”

Google’s own announcement also describes access as “very limited” during the early phase.

What Early Testers Get

The API’s main benefit is consistent scaling.

Unlike the Trends website, which rescales results between 0 and 100 for each query set, the API returns data that stays comparable across requests.

That means you can join series, extend time ranges without re-pulling history, and compare many terms in one workflow.

Data goes back 1,800 days (about five years) and updates through two days ago. You can query daily, weekly, monthly, or yearly intervals and break results down by region and sub-region.

At the launch session, Google showed example responses that included both a scaled interest value and a separate search_interest field, indicating a raw-value style metric alongside the scaled score. Google also said the alpha will not include the “Trending Now” feature.

Why There’s High Interest

If you rely on Trends for research, the consistent scaling solves a long-standing pain point with cross-term comparisons.

You can build repeatable analyses without the “re-scaled to 100” surprises that come from changing comparator sets.

For content planning, five years of history and geo breakdowns support more reliable seasonality checks and local targeting.

Looking Ahead

The small pilot suggests Google wants feedback from different types of users. Google is prioritizing applicants who have a concrete use case and can provide feedback.

In the meantime, you can continue to use the website version while preparing for API-based comparisons later.

---

Featured Image: PhotoGranary02/Shutterstock

https://www.searchenginejournal.com/google-trends-api-alpha-mueller-confirms-small-pilot-group/554078/