Use Chrome To Send Someone Directly To The Important Part Of A Web Page

If you need to share a particular sentence or paragraph from a long web page, Google Chrome can create a link that takes the recipient directly to that section and highlights the relevant text.

This is useful for sharing technical instructions, online guidance, policies, supplier terms or lengthy articles without making the recipient search through the entire page.

How To Create A Link To Highlighted Text

On a computer:

– Open the relevant web page in Chrome.

– Highlight the exact text you want to share.

– Right-click the highlighted text.

– Select Copy link to highlight.

– Paste the link into an email, Teams message or document.

When the recipient opens the link in a compatible browser, the page should open at the relevant section with the selected text highlighted.

Why This Is Useful

Ordinary web links usually take someone to the top of a page, leaving them to find the relevant information themselves. Copy link to highlight makes sharing more precise by taking them straight to an important paragraph, instruction, clause or other piece of information.

One Thing To Be Aware Of

The feature may not work with all selected content. If the option is unavailable or the link doesn’t work as expected, send the normal page link and explain where the relevant section appears.

This simple Chrome feature can save time, reduce confusion and make it easier to direct colleagues and customers to the exact information they need.

Featured Article : CAPTCHAs To Be Replaced With Privacy-First Web Verification

Cloudflare has joined forces with Mozilla, Google, Microsoft and Shopify to develop a new internet protocol designed to help websites distinguish genuine visitors from malicious bots without relying on CAPTCHAs, forced logins or invasive tracking, in what could become one of the biggest changes to how people prove their identity online in decades.

What Is PACT?

The initiative centres on a new technology called Private Access Control Tokens (PACT), which aims to solve a problem that is becoming increasingly urgent as artificial intelligence changes the nature of internet traffic.

According to Cloudflare, automated systems now generate more web traffic than humans. Cloudflare Radar data shows bots account for around 58 per cent of HTTP requests worldwide, driven in part by the rapid growth of AI assistants and autonomous software agents browsing the web on users’ behalf.

That creates a challenge for website operators. They need to distinguish legitimate visitors from malicious bots without creating frustrating barriers for genuine users or collecting excessive amounts of personal data.

How The System Works

Rather than asking users to complete CAPTCHAs, log in repeatedly or allowing websites to build detailed browser fingerprints, PACT introduces a different approach.

Trusted services that already have a genuine relationship with a user can issue an anonymous cryptographic token to that person’s browser. When the user later visits another participating website, the browser can present the token as evidence that a real person, or an authorised AI agent acting for one, is behind the request.

Importantly, the token is designed to prove legitimacy without revealing who the person is or allowing websites to reconstruct their browsing history.

Cloudflare says PACT allows websites to “verify that a visitor is a human or authorized agent while preserving privacy”, removing much of the friction associated with existing verification methods.

Why Existing Methods Are Becoming Less Effective

For years, websites have relied on CAPTCHAs, browser fingerprinting, account log-ins and behavioural analysis to defend themselves against automated abuse.

Those techniques are becoming increasingly problematic. CAPTCHAs interrupt the browsing experience, browser fingerprinting has attracted growing regulatory scrutiny because of its privacy implications, while AI systems are becoming increasingly capable of solving many traditional bot detection tests.

Cloudflare CTO Dane Knecht believes the internet is reaching a turning point. As he explained: “The way we interact with the Internet is facing a fundamental shift… As AI-powered traffic becomes widespread, existing tools to support its use are too generic and coarse.”

Rather than treating all automated traffic as malicious, PACT is intended to distinguish authorised AI agents from abusive bots.

Why The Browser Makers Are Involved

One of the most significant aspects of the announcement is the unusually broad industry collaboration behind it.

Mozilla, Google and Microsoft collectively develop the browsers used by most internet users, while Shopify brings the perspective of millions of online retailers, where every unnecessary security check can reduce sales.

Shopify Distinguished Engineer Ilya Grigorik said: “Every extra challenge, delay, or false positive can turn a purchase into an abandoned cart.” He added that PACT could help businesses distinguish legitimate shoppers and authorised AI agents “while preserving buyer privacy.”

Mozilla also sees wider benefits. Firefox CTO Bobby Holley warned that an “avalanche of automated traffic” is pushing websites towards increasingly intrusive measures simply to determine whether visitors are genuine.

What Happens Next?

It should be noted here that PACT is still at quite an early stage. The partners intend to submit the protocol for formal internet standardisation before browsers and websites begin adopting it more widely.

The technology also builds on earlier Privacy Pass standards already used in some online services, extending those ideas to support a much broader range of browsers and AI-driven web traffic.

If widely adopted, PACT could eventually become a common feature of everyday web browsing, allowing websites to authenticate visitors with far less friction while giving users greater control over their privacy.

What Does This Mean For Your Business?

For organisations, the announcement reflects a much bigger change than simply replacing CAPTCHAs. The internet is rapidly moving from a world dominated by human visitors to one where AI agents increasingly browse, search, purchase and interact with online services on behalf of people.

Businesses will therefore need new ways to identify legitimate traffic without damaging the customer experience or creating additional privacy risks. PACT represents one possible answer by allowing trust to be established without relying on invasive tracking or repeated identity checks.

Although widespread deployment is still quite some way off, the involvement of Cloudflare, Google, Microsoft, Mozilla and Shopify suggests this is more than simply another technical proposal. If the standard gains broad industry support, it could reshape how websites balance cyber security, privacy and usability as AI becomes a routine part of everyday internet activity.

Sustainability-in-Tech : AI Bots Overtaking Human Web

AI driven bots are rapidly overtaking humans as the primary consumers of online content, creating growing sustainability concerns around energy use, digital efficiency, and the future structure of the open web.

Report

The latest State of the Bots report from AI bot traffic measurement company TollBit shows a marked acceleration in automated web traffic during the second half of 2025, alongside a measurable decline in human visits. It seems that what was once framed primarily as a debate about AI training data has evolved into a broader structural change, with AI systems now reading the live internet at scale to support search, chat, and information retrieval tools.

Rising Bot Traffic And Declining Human Visits

TollBit’s analysis shows that the ratio of AI bot traffic to human traffic has changed rapidly over a short period. For example, in the first quarter of 2025, the average site monitored by TollBit saw one AI bot visit for every 200 human visits. By the end of the year, that ratio had increased to one AI bot visit for every 31 human visits.

Over the same period, human web traffic declined. Between the third and fourth quarters of 2025 alone, TollBit recorded a 5 per cent fall in human visits across its partner sites. The report stresses that these figures likely understate the true scale of automated activity, as many modern bots are designed to closely mimic human browsing behaviour.

In its findings, TollBit says “from the tests we ran, many of these web scrapers are indistinguishable from human visitors on sites”, adding that the data should be treated as conservative. This increasing difficulty in separating human and automated traffic complicates both measurement and mitigation efforts.

From Training Crawlers To Live Web Retrieval

Earlier concerns around AI and the web focused largely on large scale scraping for model training. While training related crawling continues, TollBit’s data actually shows it is no longer the dominant driver of AI bot activity.

In fact, it seems that training crawler traffic fell by around 15 per cent between the second and fourth quarters of 2025. However, over the same period, traffic from retrieval augmented generation bots increased by 33 per cent.

RAG systems, which fetch live web content to answer user prompts, allow AI tools to provide current answers rather than relying solely on static training data.

This distinction has some important implications. For example, training crawlers typically access content once and store it for offline use. RAG bots, by contrast, return to the same pages repeatedly. TollBit found that in the fourth quarter of 2025, RAG bots made roughly ten page requests for every single page request made by training bots. This repeated access reflects the growing role of AI tools as substitutes for traditional search engines and direct browsing.

The Role Of AI Search Indexing

Alongside RAG bots, AI search indexing activity is expanding rapidly. Indexing crawlers systematically map the web so that RAG systems can locate relevant pages when responding to prompts. TollBit recorded a 59 per cent increase in AI search indexer traffic between the second and fourth quarters of 2025.

This growth seems to show that AI driven search is building out its own parallel infrastructure to support real time information retrieval. While indexing has long been a feature of traditional search engines, the combination of indexing and repeated live retrieval increases the volume of automated traffic moving across the web.

Concentration Of Scraping Activity

TollBit’s data also shows that AI scraping activity is unevenly distributed across providers. For example, OpenAI’s ChatGPT User agent was identified as the most active RAG bot across monitored sites. In the fourth quarter of 2025, it averaged around five times as many scrapes per page as the second most active scraper, attributed to Meta.

Other major contributors include bots operated by Google, Perplexity, Anthropic, and Amazon, each running multiple user agents for training, indexing, and user triggered retrieval. The combined effect is a background layer of automated traffic that now rivals human browsing in scale on many sites.

Which Parts Of The Web Are Most Affected?

It should be noted here that not all content categories seem to be affected equally. For example, TollBit reports that B2B and professional sites, national news outlets, and lifestyle content are among the most heavily scraped. Technology and consumer electronics content experienced the fastest growth in scraping activity, increasing by 107 per cent since the second quarter of 2025.

According to TollBit, the most frequently scraped pages tend to relate to time sensitive topics. In the third quarter of 2025, heavily scraped URLs included political controversies and live sports coverage. By the fourth quarter, entertainment releases and shopping related content, such as streaming series and seasonal buying guides, featured more prominently.

This pattern could be said to reflect how users are increasingly turning to AI tools for up-to-date information, prompting RAG bots to revisit high demand pages repeatedly throughout the day.

The Sustainability Cost Of Repeated Access

From a sustainability perspective, the rise of RAG driven browsing introduces a less visible but growing cost. For example, each automated page request consumes energy across data centres, networks, and supporting infrastructure. When the same content is retrieved repeatedly to support similar prompts, overall energy demand increases significantly.

TollBit, therefore, describes the current environment as inefficient for both publishers and AI developers. AI companies invest heavily in scraping infrastructure, proxy services, and evasion techniques, while publishers spend increasing sums on defensive technologies. This duplication of effort results in higher processing and energy use, alongside increased indirect emissions.

In fact, the report notes that advanced scraping services can charge more than 22 dollars per 1,000 pages retrieved. At the scale required to support popular consumer AI applications, data acquisition costs alone can reach tens of millions of dollars per year. These financial costs sit alongside rising electricity demand in data centres, which sustainability researchers already identify as a growing contributor to global emissions.

Robots Txt And Escalating Inefficiency

Existing mechanisms for controlling automated access seem to have proven ineffective. For example, in the fourth quarter of 2025, around 30 per cent of AI bot scrapes recorded by TollBit did not actually comply with robots.txt permissions. In categories such as deals and shopping, non-permitted scrapes exceeded permitted ones by a factor of four.

OpenAI’s ChatGPT User bot showed the highest rate of non-compliance among major bots, accessing blocked content in 42 per cent of cases. TollBit argues that this environment encourages increasingly sophisticated evasion strategies, including IP rotation, user agent spoofing, and cloud based headless browsers.

Each layer of evasion and detection adds computational overhead. Bots expend more resources to appear human, while websites consume more resources attempting to identify and block them. From an environmental standpoint, this escalation increases energy use without delivering proportional value to end users.

Low Referral Traffic And Structural Implications

The sustainability issue is closely tied to the economics of online publishing. TollBit reports that referral traffic from AI applications remains extremely low and continues to decline. Average click through rates from AI tools actually fell from 0.8 per cent in the second quarter of 2025 to 0.27 per cent by the end of the year.

Even websites with direct licensing agreements saw some pretty sharp declines. For example, click through rates for sites with one-to-one AI deals fell from 8.8 per cent early in 2025 to 1.33 per cent in the fourth quarter. This indicates that licensing arrangements alone are not insulating publishers from reduced human traffic.

The result, therefore, appears to be a system in which machines read and reuse content at scale, while fewer people visit the original sources. For example, TollBit’s report states that “AI traffic will continue to surge and replace direct human visitors to sites”, pointing to a future in which automated systems become the primary readers of the internet.

The data suggests that this transition is already underway, with some significant implications for sustainability, digital infrastructure, and the long-term viability of the content ecosystem that AI systems depend on.

What Does This Mean For Your Organisation?

The picture emerging from TollBit’s data seems to be one of structural change rather than a short-term disruption, where AI systems are no longer just indexing the web or training on it in the background. In fact, it seems they are now repeatedly consuming live content at scale, with clear consequences for energy use, infrastructure efficiency, and the sustainability of the wider digital ecosystem. Without changes to how AI systems access content, the current pattern risks locking in higher energy demand and escalating inefficiencies across both AI development and online publishing.

For UK businesses, this trend has practical implications on several fronts. For example, organisations increasingly relying on AI tools for research, search, and decision support are indirectly contributing to rising digital energy use and associated emissions. At the same time, UK publishers, professional services firms, and content driven businesses face growing operational costs from defending their websites against automated access, while seeing diminishing human engagement in return. These pressures sit alongside wider regulatory and sustainability expectations, particularly as UK businesses are required to demonstrate progress on energy efficiency, emissions reporting, and responsible technology use.

For AI developers, publishers, regulators, and end users, the data shows that the current scrape and block dynamic appears inefficient, costly, and environmentally counterproductive. If AI systems are to become permanent fixtures in how information is accessed, it looks as though the underlying mechanics of content access will need to evolve in a way that supports sustainability, fair value exchange, and long-term viability. Without that recalibration, the growth of AI driven web consumption risks undermining both the digital economy it depends on and the sustainability goals many organisations are now expected to meet.

Tech Insight : How The Thirty-Year-Old IPv6 Still Underpins the Internet’s Growth

In this Tech Insight, we look at why IPv6 is now 30 years old, what it was designed to solve, how it works in practice, and why it continues to matter to the modern internet despite never fully replacing IPv4.

What Is IPv6?

IPv6, or Internet Protocol version 6, is the system used to identify devices on the internet and route data between them. Every device connected to the public internet needs an IP address so information can be sent to the correct destination.

IPv6 is the successor to IPv4 and uses a much larger 128 bit address format, allowing vastly more unique addresses. This expansion was designed to ensure the internet could continue to grow as more people, devices, and services came online.

Why Was A New Internet Addressing System Needed?

The origins of IPv6 lie in a problem identified more than three decades ago. Internet Protocol version 4, introduced in the early 1980s, used 32 bit addresses, allowing for around 4.3 billion unique IP addresses. At a time when the internet was largely confined to universities, research institutions, and government networks, that seemed more than sufficient.

By the early 1990s, however, growth was accelerating much faster than expected. Commercial internet service providers were emerging, personal computers were becoming commonplace, and policymakers and engineers began to worry that the available supply of IPv4 addresses would eventually run out. Without addresses, new devices could not connect to the public internet, creating a real risk of slowing innovation and economic growth.

The responsibility for solving this problem fell to the Internet Engineering Task Force, the open standards organisation that develops the technical foundations of the internet. After several years of debate and experimentation, the IETF published RFC 1883 in December 1995, formally defining Internet Protocol version 6.

What Was Different About IPv6?

The most significant change introduced by IPv6 was the expansion of the address space. For example, IPv6 uses 128 bit addresses, increasing the number of possible addresses to approximately 340 undecillion (36 zeros!). In practical terms, this removed address scarcity as a constraint on future internet growth.

IPv6 also introduced a simplified packet header (the addressing and delivery instructions for data) to improve routing efficiency, removed some legacy features that had accumulated in IPv4, and standardised support for multicast traffic. Address assignment was redesigned through stateless address autoconfiguration, which allowed devices to generate their own addresses automatically when connecting to a network, without relying on manual configuration.

Security

Security considerations were part of the design from the outset. For example, support for IPsec was specified within IPv6, reflecting the growing importance of encryption and authentication on the public internet. Even so, IPv6 was deliberately conservative in that it was designed to change as little as possible beyond what was required to address scaling limits.

Not Backward Compatible

However, it’s worth noting here that IPv6 was not designed to be backward compatible with IPv4, i.e., IPv6 cannot directly communicate with IPv4, a decision that proved controversial because devices using one protocol could not directly communicate with devices using the other without translation mechanisms or running both protocols in parallel.

Why IPv6 Did Not Replace IPv4

At the time IPv6 was standardised, many assumed the internet would gradually migrate from IPv4 to IPv6. However, that transition never occurred in a clean or coordinated way.

Instead, network operators adopted Network Address Translation, known as NAT. NAT allows many devices to share a single public IPv4 address by using private address ranges internally. Homes, offices, and even entire mobile networks could connect large numbers of devices while consuming very few public IPv4 addresses.

This workaround fundamentally changed the incentives around IPv6 adoption. NAT was popular because it was relatively easy to deploy, worked with existing equipment, and avoided the need for large scale network redesign. Over time, IPv4 addresses became scarce but still usable, with regional internet registries overseeing address transfers between organisations.

As a result, IPv6 deployment slowed. Vendors had limited motivation to prioritise IPv6 support, and many organisations saw little short term benefit in migrating. Dual stack operation, where IPv4 and IPv6 run side by side, increased complexity and operational cost.

Where IPv6 Has Actually Been Successful

Judging IPv6 purely by whether it replaced IPv4 misses how the protocol is used today. In fact, IPv6 has carried much of the internet’s growth over the past decade, particularly in environments where scaling pressures are highest.

Mobile networks are a clear example. Many operators now deploy IPv6 as the default protocol for smartphones, using translation technologies only when IPv4 connectivity is required. This approach allows mobile providers to connect millions of devices without relying entirely on increasingly complex NAT systems.

Cloud infrastructure also shows a similar pattern. For example, large providers support IPv6 extensively within their internal networks and data centres. New virtual machines and services are often IPv6 capable by default, even if they still need to interoperate with IPv4 clients.

Data from Google, the Asia Pacific Network Information Centre, and Cloudflare shows that IPv6 adoption remains uneven worldwide, with global usage hovering in the mid 40 per cent range, some countries exceeding 50 per cent adoption, and others still relying heavily on IPv4.

What IPv6 Means for Modern Internet Architecture

Over the past 30 years, the internet has evolved in ways few engineers anticipated in the 1990s. For example, applications increasingly rely on domain names rather than fixed IP addresses, encryption is now the default for web traffic, and protocols such as QUIC reduce reliance on long lived client addressing by operating at higher layers.

These changes have led some to question whether IP addressing matters as much as it once did. In reality, scalable addressing still underpins everything. Data must still be routed efficiently across global networks, and infrastructure still needs predictable, manageable address allocation.

Simplifies Large Scale Network Design

In fact, IPv6 allows networks to be designed more simply at scale because large address blocks can be allocated hierarchically, which reduces routing complexity and makes networks easier to manage, particularly in data centres, content delivery networks, and emerging Internet of Things deployments where device counts can grow rapidly.

Ongoing Challenges

Despite its advantages, IPv6 is not without its drawbacks. For example, running IPv4 and IPv6 side by side increases operational overhead because security teams must monitor and protect two protocols at once, and misconfigured IPv6 can create unexpected exposure if administrators focus only on IPv4 controls.

Also, some older hardware and software either lacks IPv6 support or implements it poorly, which leads organisations in those environments to disable IPv6 entirely to avoid instability, even though doing so can create long term technical debt.

IPv6 migration also requires planning, testing, and staff training, and analysts at Gartner have repeatedly noted that many organisations struggle to justify IPv6 projects without external pressure such as address exhaustion, cloud pricing models, or regulatory expectations.

Why IPv6 Still Matters in 2026

As the global pool of unused IPv4 addresses has become effectively exhausted, supporting new services, devices, and networks increasingly depends on complex translation layers, which are harder to scale and manage over time, while IPv6 provides a way to support continued growth without compounding that complexity indefinitely.

IPv6 was designed as underlying infrastructure rather than a visible end user technology, with its value lying in the capacity and flexibility it provides to support internet expansion as higher level protocols, encryption, and application architectures continue to evolve.

Viewed in that context, IPv6 has not failed, but has quietly fulfilled its original purpose by allowing the internet to keep growing without breaking under the strain of address scarcity and architectural workarounds.

What Does This Mean For Your Business?

IPv6’s 30 year history shows that it was never meant to be a dramatic switchover moment, but a long term safety valve for internet growth, and that role is now clearer than ever. IPv4 continues to function through layers of workarounds, trading markets, and translation systems, while IPv6 quietly carries much of the internet’s newest traffic, particularly where scale and automation matter most. The result is an internet that runs on both protocols at once, not because that was the ideal outcome, but because it proved to be the most practical one.

For UK businesses, this creates a more immediate and pragmatic challenge than a theoretical one. For example, organisations planning cloud migrations, rolling out new digital services, or deploying large numbers of connected devices increasingly need to understand how IPv6 fits into their infrastructure, even if customers never notice it directly. Ignoring IPv6 entirely can introduce hidden risks, from security blind spots to unexpected compatibility issues with cloud platforms and mobile networks that already assume IPv6 support by default.

For network operators, regulators, vendors, and standards bodies, IPv6 remains a reminder that core internet technologies evolve slowly and unevenly, shaped as much by economics and operational reality as by technical design. Thirty years on, IPv6 has neither transformed the internet nor been left behind by it. Instead, it seems to have become part of the underlying fabric that allows the internet to keep expanding, quietly doing the job it was built to do while the debate about its future continues.

Company Check : Another Cloudflare Outage Raises Fresh Concerns

Cloudflare has suffered its second major service outage in less than a month, briefly taking a substantial portion of the internet offline and prompting renewed questions about the resilience of the infrastructure many organisations now rely on.

Friday 5 December Outage

This latest incident occurred on Friday 5 December, when websites around the world began returning blank pages, stalled login screens and 500 error messages from around 08:47 GMT. Cloudflare confirmed that the problem affected part of its global network and that a significant number of high profile customers were impacted. Although services were largely restored by 09:12, the disruption was extensive enough to affect millions of users and thousands of online businesses during a busy weekday morning.

What Happened And Why Did It Spread So Quickly?

Cloudflare acknowledged shortly after the incident that the outage was caused by an internal change to how its Web Application Firewall processes incoming requests. The change had been deployed as part of an emergency response to a newly disclosed security vulnerability in React Server Components. The flaw, widely discussed across the software industry, could allow remote code execution in some applications built using React and Next.js. Cloudflare introduced new rules to help shield its customers from potential exploitation while they applied their own patches.

A Bug Was Triggered

During that process, a long standing bug in how the Web Application Firewall parses request bodies was triggered under the specific conditions created by the mitigation. This resulted in errors being generated within parts of Cloudflare’s network responsible for inspecting and forwarding traffic. In practice, it meant that requests processed through those systems began failing, which is why so many sites appeared blank or unresponsive.

Not A Cyber Attack

Cloudflare’s Chief Technology Officer commented publicly that this was not the result of an attack and was instead linked to logging changes implemented to help address the React vulnerability. The company has since published a technical summary of the issue, stating that it was working on a full review to prevent similar failures from recurring.

The speed of the disruption reflected Cloudflare’s central role in global web infrastructure. For example, the company provides security, performance optimisation and traffic routing services for a large proportion of internet services. This means that when a fault is introduced in a critical part of its platform, the effects can cascade quickly across many unrelated industries and geographies.

Which Services Were Impacted?

Reports from affected organisations and users indicated that large platforms such as LinkedIn, Zoom, Canva and Discord were among the most prominent names disrupted. E commerce providers including Shopify, Deliveroo and Vinted also experienced problems. Media outlets and entertainment platforms saw outages, as did financial services and stock trading apps in some regions. Ironically, even DownDetector, the independent website that tracks service outages, was temporarily unavailable because it also runs on Cloudflare’s network.

For many businesses the disruption manifested as failed page loads, broken checkout journeys or services timing out without explanation. It should be noted that, although the outage was brief, these symptoms can have very real impacts. For example, retailers risk abandoned purchases, subscription platforms face customer frustration and organisations offering time critical services can see immediate operational strain.

How This Compares With The November Outage

The December outage arrived only weeks after Cloudflare’s previous incident on 18 November, which was far longer and affected a wider range of services. That disruption began around midday UTC and took several hours to fully resolve.

Cloudflare later explained that the November issue stemmed from an automatically generated configuration file used by its Bot Management system. A change to database permissions caused the file to grow far beyond its intended size. When the oversized file was synchronised across the network, it caused a core traffic routing module to fail repeatedly. Major services including X, ChatGPT, Spotify and large gaming platforms all experienced significant downtime.

Both The Results of Internal Changes

It seems, therefore, that the two outages were technically unrelated. The November incident was caused by a configuration file that overwhelmed a key proxying process, while the December disruption was caused by a logic error triggered within the Web Application Firewall. However, what links them is that both were the result of internal changes aimed at improving security and performance, and both exposed fragilities within a highly automated global system.

Reactions From Cloudflare And The Wider Industry

Cloudflare has stated publicly that any outage of this scale is unacceptable and has acknowledged the frustration caused to customers. After the November incident, its chief executive promised a series of improvements to configuration handling, kill switches and automated safety checks. The fact that a second issue occurred so soon afterwards has prompted visible concern from customers and industry observers about the platform’s change control processes.

The Danger Of Relying On A Small Number Of Infrastructure Providers

Security experts have emphasised the broader lesson here, i.e., that many organisations now rely heavily on a small number of global infrastructure providers. Cloudflare’s size and technical capabilities offer benefits in terms of speed and protection from attacks, yet this scale also creates single points of failure. If a major provider experiences a fault, thousands of websites and applications can be disrupted almost instantly.

Industry groups have urged organisations to reassess their resilience strategies. Some policy specialists argue that businesses should identify where they rely on a single vendor for critical operations and explore ways to diversify. This might involve adopting multiple cloud providers, splitting content delivery across different networks or architecting applications so they degrade gracefully rather than fail outright when a dependency becomes unavailable.

Customers And Competitors

For Cloudflare’s customers, the December outage reinforces the need to balance performance gains with risk planning. Many organisations use Cloudflare for security filtering, caching, bot protection and traffic routing, meaning a failure in any of those layers can have immediate consequences for availability.

Also, competitors in the content delivery and cloud security sector may see renewed interest in multi provider approaches. This does not necessarily mean businesses will move away from Cloudflare, given its extensive footprint and capability, but it is likely to encourage more organisations to build redundancy around critical services.

Regulators are also likely to take note of what has happened at Cloudflare. For example, European and UK frameworks focusing on operational resilience, such as NIS2 and DORA, place increasing emphasis on understanding and mitigating third party risk. Repeated outages at a major provider may strengthen the argument for closer oversight of critical internet infrastructure and more transparent reporting requirements.

What Happens Next?

Cloudflare has said it will publish a full post incident analysis and will continue making changes to improve reliability across its platform. The company has already committed to reviewing how new security mitigations are validated before deployment, in addition to strengthening internal safeguards that determine how changes propagate across the network.

For customers and other stakeholders, the incident is another reminder that internet resilience depends not only on defending against attackers but also on managing the risks introduced by routine operational changes. The growing complexity of web infrastructure has made this increasingly challenging, and the recent outages have placed long term operational resilience firmly back on the agenda.

What Does This Mean For Your Business?

The pace of software change, the pressure to react quickly to new vulnerabilities and the scale at which providers now operate mean that even well intentioned updates can clearly create unexpected instability. This latest incident from Cloudflare shows how a single adjustment deep inside a security layer can move rapidly through global systems and affect businesses with no direct connection to the underlying flaw. It also reinforces why resilience planning needs to be treated as a strategic priority rather than an operational afterthought.

UK businesses, in particular, face a growing need to understand how their digital supply chains actually function. Many organisations depend on Cloudflare without realising how many of their core services sit behind it. The outage demonstrated that customer experience, revenue and even internal operations can be affected within minutes if one vendor encounters a problem. These short disruptions may not make headlines for long, yet they expose gaps in continuity planning that boards and technology teams are being pushed to close, especially as regulators sharpen their expectations around third party risk.

Although Cloudflare’s competitors may now really want to highlight the benefits of multi provider architectures and the reduced exposure this can offer, the practical reality is that Cloudflare’s scale, speed and security tooling remain difficult to replicate. Most organisations may not currently be planning to abandon the platform but they may be looking for ways to introduce redundancy around it, whether by spreading workloads, adding backup routing options or designing services that fail more gracefully when a dependency falters. In other words, the market is now moving towards diversification rather than replacement.

Other stakeholders have lessons to learn from all this as well. For example, regulators will continue scrutinising outages that affect large sections of the internet, particularly where they touch financial services, transport or healthcare. Also, investors will look at whether Cloudflare can demonstrate consistent improvements after two incidents so close together. Developers and security teams across the industry may now reflect on the risks involved in rolling out urgent protections at speed, especially when the underlying software landscape is evolving as quickly as it is today.

Cloudflare remains a central pillar of global internet infrastructure, and that reality brings both advantages and pressures. Although pretty inconvenient and costly to many businesses and their users, the recent outages do not change the importance of Cloudflare, but they do highlight how essential it has become to strengthen resilience around the entire ecosystem. This means that organisations that choose to invest in understanding their dependencies and designing for failure may be better positioned to handle future shocks, whatever their source, and will place themselves on far stronger footing as digital systems continue to grow in complexity.

Company Check : Cloudflare Outage Was NOT a Cyber Attack

Cloudflare CEO Matthew Prince has clarified that its recent global outage was caused by an internal configuration error and a latent software flaw rather than any form of cyber attack.

A Major Disruption Across Large Parts Of The Internet

The outage of internet infrastructure company Cloudflare began at around 11:20 UTC on 18 November 2025 and lasted until shortly after 17:00, disrupting access to many of the world’s most visited platforms. For example, services including X, ChatGPT, Spotify, Shopify, Etsy, Bet365, Canva and multiple gaming platforms experienced periods of failure as Cloudflare’s edge network returned widespread 5xx errors. Cloudflare itself described the disruption as its most serious since 2019, with a significant portion of its global traffic unable to route correctly for several hours.

Symptoms

The symptoms were varied, ranging from slow-loading pages to outright downtime. For example, some users saw error pages stating that Cloudflare could not complete the request and needed the user to “unblock challenges.cloudflare.com”. For businesses that rely on Cloudflare’s CDN, security filtering and DDoS protection, even short periods of failure can stall revenue, block logins, and create customer support backlogs.

Given Cloudflare’s reach (serving a substantial share of global web traffic), the effect was not confined to one sector or region. In fact, millions of individuals and businesses were affected, even if they had no direct relationship with Cloudflare. That level of impact meant early scrutiny was intense and immediate.

Why Many Suspected A Major Cyber Attack

In the early stages, the pattern of failures resembled those of a large-scale DDoS campaign. Cloudflare was already dealing with unusually high-volume attacks from the Aisuru botnet in recent weeks, raising the possibility that this latest incident might have been another escalation. Internal teams initially feared that the sudden spike in errors and fluctuating recovery cycles could reflect a sophisticated threat actor pushing new attack techniques.

The confusion deepened when Cloudflare’s independent status page also went offline. Since it is hosted outside of Cloudflare’s own infrastructure, this coincidence created an impression, inside and outside the company, that a skilled attacker could be targeting both Cloudflare’s infrastructure and the third-party service used for its status platform.

Commentary on social media, as well as early industry analysis, reflected that uncertainty. With so many services dropping offline at once, it seemed easy to assume the incident must have been caused by malicious activity or a previously unseen DDoS vector. Prince has acknowledged that even within Cloudflare, the team initially viewed the outage through that lens.

Prince’s Explanation Of What Actually Happened

Once the situation stabilised, Prince published an unusually detailed account explaining that the outage originated from Cloudflare’s bot management system and the internal processes that feed it. In his statement, he says the root of the problem lay in a configuration change to the permissions in a ClickHouse database cluster that generates a “feature file” used by Cloudflare’s machine learning model for evaluating bot behaviour.

What??

It seems that, according to Mr Prince, the bot management system assigns a “bot score” to every inbound request and to do that, it relies on a regularly refreshed feature file that lists the traits used by the model to classify traffic. This file is updated roughly every five minutes and pushed rapidly across Cloudflare’s entire network.

It seems that, during a planned update to database permissions, the query responsible for generating the feature file began returning duplicate rows from an additional schema. This caused the file to grow significantly. Cloudflare’s proxy software includes a strict limit on how many features can be loaded for performance reasons. When the oversized file arrived, the system attempted to load it, exceeded the limit, and immediately panicked. That panic cascaded into Cloudflare’s core proxy layer, triggering 5xx errors across key services.

Stuck In A Cycle

Not all ClickHouse nodes received the permissions update at the same moment, meaning that Cloudflare’s network then entered a cycle of partial recovery and renewed failure. For example, every five minutes, depending on which node generated the file, the network loaded either a valid configuration or a broken one. That pattern created the unusual “flapping” behaviours seen in error logs and made diagnosis harder.

However, once engineers identified the malformed feature file as the cause, they stopped the automated distribution process, injected a known-good file, and began restarting affected services. Traffic began returning to normal around 14:30 UTC, with full stability achieved by 17:06.

Why The Framing Matters To Cloudflare

Prince’s post was clear and emphatic on one point i.e., that this event did not involve a cyber attack of any kind. The language used in the post, e.g., phrases such as “not caused, directly or indirectly, by a cyber attack”, signalled an intent to remove any ambiguity.

There may be several reasons for this emphasis. For example, Cloudflare operates as a core piece of internet security infrastructure. Any suggestion that the company suffered a breach could have wide-ranging consequences for customer confidence, regulatory compliance, and Cloudflare’s standing as a provider trusted to mitigate threats rather than succumb to them.

Also, transparency is a competitive factor in the infrastructure market. By releasing a highly granular breakdown early, Cloudflare is signalling to customers and regulators that the incident, though serious, stemmed from internal engineering assumptions and can be addressed with engineering changes rather than indicating a persistent security failure.

It’s also the case that many customers, particularly in financial services, government, and regulated sectors, must report cyber incidents to authorities. Establishing that no malicious actor was involved avoids triggering those processes for thousands of Cloudflare customers.

The Wider Impact On Businesses

The outage arrived at a time when the technology sector is already dealing with the operational fallout of several major incidents this year. For example, recent failures at major cloud providers, including AWS and Azure, have contributed to rising concerns about “concentration risk”, i.e., the danger created when many businesses depend on a small number of providers for critical digital infrastructure.

Analysts have estimated that the direct and indirect costs of the Cloudflare outage could actually reach into the hundreds of millions of dollars once downstream impacts on online retailers, payment providers and services built on Shopify, Etsy and other platforms are included. For small and medium-sized UK businesses, downtime during working hours can lead to missed orders, halted support systems, and reduced customer trust.

For regulators, this incident looks like being part of a trend of high-profile disruptions at large providers. Sectors such as financial services already face strict operational resilience requirements, and there is growing speculation that similar expectations may extend to more industries if incidents continue.

How Cloudflare Is Responding

Prince outlined several steps that Cloudflare is now working on to avoid similar scenarios in future. These include:

– Hardening ingestion of internal configuration files so they are subject to the same safety checks as customer-generated inputs.

– Adding stronger global kill switches to stop faulty files before they propagate.

– Improving how the system handles crashes and error reporting.

– Reviewing failure modes across core proxy modules so that a non-essential feature cannot cause critical traffic to fail.

It seems that Cloudflare’s engineering community has welcomed the transparency, though some external practitioners have questioned why a single configuration file was able to impact so much of the network, and why existing safeguards did not prevent it from propagating globally.

Prince has acknowledged the severity of the incident, describing the outage as “deeply painful” for the team and reiterating that Cloudflare views any interruption to its core traffic delivery as unacceptable.

What Does This Mean For Your Business?

Cloudflare’s account of the incident seems to leave little doubt that this was a preventable internal failure rather than an external threat, and that distinction matters for every organisation that relies on it. The explanation shows how a single flawed process can expose structural weaknesses when so much of the internet depends on centralised infrastructure. For UK businesses, the lesson is that operational resilience cannot be outsourced entirely, even to a provider with Cloudflare’s reach and engineering reputation. The incident reinforces the need for realistic contingency planning, multi-vendor architectures where feasible, and a clear understanding of how a supplier’s internal workings can affect day-to-day operations.

There is also a broader industry point here. For example, outages at Cloudflare, AWS, Azure and other major players are now becoming too significant to dismiss as isolated events. They actually highlight weaknesses in how complex cloud ecosystems are built and maintained, as well as the limits of automation when oversight relies on assumptions that may not be tested until something breaks at scale. Prince’s emphasis on transparency is helpful, but it also raises questions about how often configuration-driven risks are being overlooked across the industry and how reliably safeguards are enforced inside systems that evolve at speed.

Stakeholders from regulators to hosting providers will surely be watching how quickly Cloudflare implements its promised changes and how effective those measures prove to be. Investors and enterprise customers may also be looking for signs that the underlying engineering and operational processes are becoming more robust, not just patched in response to this incident. Prince’s framing makes clear that this was not a compromise of Cloudflare’s security perimeter, but the reliance on a single configuration mechanism that could bring down so many services is likely to remain a point of scrutiny.

The most immediate implication for customers is probably a renewed focus on the practical realities of dependency. Even organisations that never interact with Cloudflare directly were affected, which shows how embedded its infrastructure is in the modern web. UK businesses, in particular, may need to reassess where their digital supply chains concentrate risk and how disruption at a provider they do not contract with can still reach them. The outage serves as a reminder that resilience is not just about defending against attackers but preparing for internal faults in external systems that sit far beyond a company’s control.