All posts by Matthew Prince

Cloudflare outage on November 18, 2025

2025-11-18 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/18-november-2025-outage/

On 18 November 2025 at 11:20 UTC (all times in this blog are UTC), Cloudflare’s network began experiencing significant failures to deliver core network traffic. This showed up to Internet users trying to access our customers’ sites as an error page indicating a failure within Cloudflare’s network.

The issue was not caused, directly or indirectly, by a cyber attack or malicious activity of any kind. Instead, it was triggered by a change to one of our database systems’ permissions which caused the database to output multiple entries into a “feature file” used by our Bot Management system. That feature file, in turn, doubled in size. The larger-than-expected feature file was then propagated to all the machines that make up our network.

The software running on these machines to route traffic across our network reads this feature file to keep our Bot Management system up to date with ever changing threats. The software had a limit on the size of the feature file that was below its doubled size. That caused the software to fail.

After we initially wrongly suspected the symptoms we were seeing were caused by a hyper-scale DDoS attack, we correctly identified the core issue and were able to stop the propagation of the larger-than-expected feature file and replace it with an earlier version of the file. Core traffic was largely flowing as normal by 14:30. We worked over the next few hours to mitigate increased load on various parts of our network as traffic rushed back online. As of 17:06 all systems at Cloudflare were functioning as normal.

We are sorry for the impact to our customers and to the Internet in general. Given Cloudflare’s importance in the Internet ecosystem any outage of any of our systems is unacceptable. That there was a period of time where our network was not able to route traffic is deeply painful to every member of our team. We know we let you down today.

This post is an in-depth recount of exactly what happened and what systems and processes failed. It is also the beginning, though not the end, of what we plan to do in order to make sure an outage like this will not happen again.

The outage

The chart below shows the volume of 5xx error HTTP status codes served by the Cloudflare network. Normally this should be very low, and it was right up until the start of the outage.

The volume prior to 11:20 is the expected baseline of 5xx errors observed across our network. The spike, and subsequent fluctuations, show our system failing due to loading the incorrect feature file. What’s notable is that our system would then recover for a period. This was very unusual behavior for an internal error.

The explanation was that the file was being generated every five minutes by a query running on a ClickHouse database cluster, which was being gradually updated to improve permissions management. Bad data was only generated if the query ran on a part of the cluster which had been updated. As a result, every five minutes there was a chance of either a good or a bad set of configuration files being generated and rapidly propagated across the network.

This fluctuation made it unclear what was happening as the entire system would recover and then fail again as sometimes good, sometimes bad configuration files were distributed to our network. Initially, this led us to believe this might be caused by an attack. Eventually, every ClickHouse node was generating the bad configuration file and the fluctuation stabilized in the failing state.

Errors continued until the underlying issue was identified and resolved starting at 14:30. We solved the problem by stopping the generation and propagation of the bad feature file and manually inserting a known good file into the feature file distribution queue. And then forcing a restart of our core proxy.

The remaining long tail in the chart above is our team restarting remaining services that had entered a bad state, with 5xx error code volume returning to normal at 17:06.

The following services were impacted:

Service / Product	Impact description
Core CDN and security services	HTTP 5xx status codes. The screenshot at the top of this post shows a typical error page delivered to end users.
Turnstile	Turnstile failed to load.
Workers KV	Workers KV returned a significantly elevated level of HTTP 5xx errors as requests to KV’s “front end” gateway failed due to the core proxy failing.
Dashboard	While the dashboard was mostly operational, most users were unable to log in due to Turnstile being unavailable on the login page.
Email Security	While email processing and delivery were unaffected, we observed a temporary loss of access to an IP reputation source which reduced spam-detection accuracy and prevented some new-domain-age detections from triggering, with no critical customer impact observed. We also saw failures in some Auto Move actions; all affected messages have been reviewed and remediated.
Access	Authentication failures were widespread for most users, beginning at the start of the incident and continuing until the rollback was initiated at 13:05. Any existing Access sessions were unaffected. All failed authentication attempts resulted in an error page, meaning none of these users ever reached the target application while authentication was failing. Successful logins during this period were correctly logged during this incident. Any Access configuration updates attempted at that time would have either failed outright or propagated very slowly. All configuration updates are now recovered.

As well as returning HTTP 5xx errors, we observed significant increases in latency of responses from our CDN during the impact period. This was due to large amounts of CPU being consumed by our debugging and observability systems, which automatically enhance uncaught errors with additional debugging information.

How Cloudflare processes requests, and how this went wrong today

Every request to Cloudflare takes a well-defined path through our network. It could be from a browser loading a webpage, a mobile app calling an API, or automated traffic from another service. These requests first terminate at our HTTP and TLS layer, then flow into our core proxy system (which we call FL for “Frontline”), and finally through Pingora, which performs cache lookups or fetches data from the origin if needed.

We previously shared more detail about how the core proxy works here.

As a request transits the core proxy, we run the various security and performance products available in our network. The proxy applies each customer’s unique configuration and settings, from enforcing WAF rules and DDoS protection to routing traffic to the Developer Platform and R2. It accomplishes this through a set of domain-specific modules that apply the configuration and policy rules to traffic transiting our proxy.

One of those modules, Bot Management, was the source of today’s outage.

Cloudflare’s Bot Management includes, among other systems, a machine learning model that we use to generate bot scores for every request traversing our network. Our customers use bot scores to control which bots are allowed to access their sites — or not.

The model takes as input a “feature” configuration file. A feature, in this context, is an individual trait used by the machine learning model to make a prediction about whether the request was automated or not. The feature configuration file is a collection of individual features.

This feature file is refreshed every few minutes and published to our entire network and allows us to react to variations in traffic flows across the Internet. It allows us to react to new types of bots and new bot attacks. So it’s critical that it is rolled out frequently and rapidly as bad actors change their tactics quickly.

A change in our underlying ClickHouse query behaviour (explained below) that generates this file caused it to have a large number of duplicate “feature” rows. This changed the size of the previously fixed-size feature configuration file, causing the bots module to trigger an error.

As a result, HTTP 5xx error codes were returned by the core proxy system that handles traffic processing for our customers, for any traffic that depended on the bots module. This also affected Workers KV and Access, which rely on the core proxy.

Unrelated to this incident, we were and are currently migrating our customer traffic to a new version of our proxy service, internally known as FL2. Both versions were affected by the issue, although the impact observed was different.

Customers deployed on the new FL2 proxy engine, observed HTTP 5xx errors. Customers on our old proxy engine, known as FL, did not see errors, but bot scores were not generated correctly, resulting in all traffic receiving a bot score of zero. Customers that had rules deployed to block bots would have seen large numbers of false positives. Customers who were not using our bot score in their rules did not see any impact.

Throwing us off and making us believe this might have been an attack was another apparent symptom we observed: Cloudflare’s status page went down. The status page is hosted completely off Cloudflare’s infrastructure with no dependencies on Cloudflare. While it turned out to be a coincidence, it led some of the team diagnosing the issue to believe that an attacker may be targeting both our systems as well as our status page. Visitors to the status page at that time were greeted by an error message:

In the internal incident chat room, we were concerned that this might be the continuation of the recent spate of high volume Aisuru DDoS attacks:

The query behaviour change

I mentioned above that a change in the underlying query behaviour resulted in the feature file containing a large number of duplicate rows. The database system in question uses ClickHouse’s software.

For context, it’s helpful to know how ClickHouse distributed queries work. A ClickHouse cluster consists of many shards. To query data from all shards, we have so-called distributed tables (powered by the table engine Distributed) in a database called default. The Distributed engine queries underlying tables in a database r0. The underlying tables are where data is stored on each shard of a ClickHouse cluster.

Queries to the distributed tables run through a shared system account. As part of efforts to improve our distributed queries security and reliability, there’s work being done to make them run under the initial user accounts instead.

Before today, ClickHouse users would only see the tables in the default database when querying table metadata from ClickHouse system tables such as system.tables or system.columns.

Since users already have implicit access to underlying tables in r0, we made a change at 11:05 to make this access explicit, so that users can see the metadata of these tables as well. By making sure that all distributed subqueries can run under the initial user, query limits and access grants can be evaluated in a more fine-grained manner, avoiding one bad subquery from a user affecting others.

The change explained above resulted in all users accessing accurate metadata about tables they have access to. Unfortunately, there were assumptions made in the past, that the list of columns returned by a query like this would only include the “default” database:

SELECT name, type FROM system.columns WHERE table = 'http_requests_features' order by name;

Note how the query does not filter for the database name. With us gradually rolling out the explicit grants to users of a given ClickHouse cluster, after the change at 11:05 the query above started returning “duplicates” of columns because those were for underlying tables stored in the r0 database.

This, unfortunately, was the type of query that was performed by the Bot Management feature file generation logic to construct each input “feature” for the file mentioned at the beginning of this section.

The query above would return a table of columns like the one displayed (simplified example):

However, as part of the additional permissions that were granted to the user, the response now contained all the metadata of the r0 schema effectively more than doubling the rows in the response ultimately affecting the number of rows (i.e. features) in the final file output.

Memory preallocation

Each module running on our proxy service has a number of limits in place to avoid unbounded memory consumption and to preallocate memory as a performance optimization. In this specific instance, the Bot Management system has a limit on the number of machine learning features that can be used at runtime. Currently that limit is set to 200, well above our current use of ~60 features. Again, the limit exists because for performance reasons we preallocate memory for the features.

When the bad file with more than 200 features was propagated to our servers, this limit was hit — resulting in the system panicking. The FL2 Rust code that makes the check and was the source of the unhandled error is shown below:

This resulted in the following panic which in turn resulted in a 5xx error:

thread fl2_worker_thread panicked: called Result::unwrap() on an Err value

Other impact during the incident

Other systems that rely on our core proxy were impacted during the incident. This included Workers KV and Cloudflare Access. The team was able to reduce the impact to these systems at 13:04, when a patch was made to Workers KV to bypass the core proxy. Subsequently, all downstream systems that rely on Workers KV (such as Access itself) observed a reduced error rate.

The Cloudflare Dashboard was also impacted due to both Workers KV being used internally and Cloudflare Turnstile being deployed as part of our login flow.

Turnstile was impacted by this outage, resulting in customers who did not have an active dashboard session being unable to log in. This showed up as reduced availability during two time periods: from 11:30 to 13:10, and between 14:40 and 15:30, as seen in the graph below.

The first period, from 11:30 to 13:10, was due to the impact to Workers KV, which some control plane and dashboard functions rely upon. This was restored at 13:10, when Workers KV bypassed the core proxy system.

The second period of impact to the dashboard occurred after restoring the feature configuration data. A backlog of login attempts began to overwhelm the dashboard. This backlog, in combination with retry attempts, resulted in elevated latency, reducing dashboard availability. Scaling control plane concurrency restored availability at approximately 15:30.

Remediation and follow-up steps

Now that our systems are back online and functioning normally, work has already begun on how we will harden them against failures like this in the future. In particular we are:

Hardening ingestion of Cloudflare-generated configuration files in the same way we would for user-generated input
Enabling more global kill switches for features
Eliminating the ability for core dumps or other error reports to overwhelm system resources
Reviewing failure modes for error conditions across all core proxy modules

Today was Cloudflare’s worst outage since 2019. We’ve had outages that have made our dashboard unavailable. Some that have caused newer features to not be available for a period of time. But in the last 6+ years we’ve not had another outage that has caused the majority of core traffic to stop flowing through our network.

An outage like today is unacceptable. We’ve architected our systems to be highly resilient to failure to ensure traffic will always continue to flow. When we’ve had outages in the past it’s always led to us building new, more resilient systems.

On behalf of the entire team at Cloudflare, I would like to apologize for the pain we caused the Internet today.

Time (UTC)	Status	Description
11:05	Normal.	Database access control change deployed.
11:28	Impact starts.	Deployment reaches customer environments, first errors observed on customer HTTP traffic.
11:32-13:05	The team investigated elevated traffic levels and errors to Workers KV service.	The initial symptom appeared to be degraded Workers KV response rate causing downstream impact on other Cloudflare services. Mitigations such as traffic manipulation and account limiting were attempted to bring the Workers KV service back to normal operating levels. The first automated test detected the issue at 11:31 and manual investigation started at 11:32. The incident call was created at 11:35.
13:05	Workers KV and Cloudflare Access bypass implemented — impact reduced.	During investigation, we used internal system bypasses for Workers KV and Cloudflare Access so they fell back to a prior version of our core proxy. Although the issue was also present in prior versions of our proxy, the impact was smaller as described below.
13:37	Work focused on rollback of the Bot Management configuration file to a last-known-good version.	We were confident that the Bot Management configuration file was the trigger for the incident. Teams worked on ways to repair the service in multiple workstreams, with the fastest workstream a restore of a previous version of the file.
14:24	Stopped creation and propagation of new Bot Management configuration files.	We identified that the Bot Management module was the source of the 500 errors and that this was caused by a bad configuration file. We stopped automatic deployment of new Bot Management configuration files.
14:24	Test of new file complete.	We observed successful recovery using the old version of the configuration file and then focused on accelerating the fix globally.
14:30	Main impact resolved. Downstream impacted services started observing reduced errors.	A correct Bot Management configuration file was deployed globally and most services started operating correctly.
17:06	All services resolved. Impact ends.	All downstream services restarted and all operations fully restored.

Cloudflare’s 2025 Annual Founders’ Letter

2025-09-21 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/cloudflare-2025-annual-founders-letter/

Cloudflare launched 15 years ago this week. We like to celebrate our birthday by announcing new products and features that give back to the Internet, which we’ll do a lot of this week. But, on this occasion, we’ve also been thinking about what’s changed on the Internet over the last 15 years and what has not.

With some things there’s been clear progress: when we launched in 2010 less than 10 percent of the Internet was encrypted, today well over 95 percent is encrypted. We’re proud of the role we played in making that happen.

Some other areas have seen limited progress: IPv6 adoption has grown steadily but painfully slowly over the last 15 years, in spite of our efforts. That’s a problem because as IPv4 addresses have become scarce and expensive it’s held back new entrants and driven up the costs of things like networking and cloud computing.

The Internet’s Business Model

Still other things have remained remarkably consistent: the basic business model of the Internet has for the last 15 years been the same — create compelling content, find a way to be discovered, and then generate value from the resulting traffic. Whether that was through ads or subscriptions or selling things or just the ego of knowing that someone is consuming what you created, traffic generation has been the engine that powered the Internet we know today.

Make no mistake, the Internet has never been free. There’s always been a reward system that transferred value from consumers to creators and, in doing so, filled the Internet with content. Had the Internet not had that reward system it wouldn’t be nearly as vibrant as it is today.

A bit of a trivia aside: why did Cloudflare never build an ad blocker despite many requests? Because, as imperfect as they are, ads have been the only micropayment system that has worked at scale to encourage an open Internet while also compensating content creators for their work. Our mission is to help build a better Internet, and a core value is that we’re principled, so we weren’t going to hamper the Internet’s fundamental business model.

Traffic ≠ Value

But that same traffic-based reward system has also created many of the problems we lament about the current state of the Internet. Traffic has always been an imperfect proxy for value. Over the last 15 years we’ve watched more of the Internet driven by annoying clickbait or dangerous ragebait. Entire media organizations have built their businesses with a stated objective of writing headlines to generate the maximum cortisol response because that’s what generates the maximum amount of traffic.

Over the years, Cloudflare has at times faced calls for us to intervene and control what content can be published online. As an infrastructure provider, we’ve never felt we were the right place for those editorial decisions to be made. But it wasn’t because we didn’t worry about the direction the traffic-incentivized Internet seemed to be headed. It always seemed like what fundamentally needed to change was not more content moderation at the infrastructure level but instead a healthier incentive system for content creation.

Today the conditions to bring about that change may be happening. In the last year, something core to the Internet we’ve all known has changed. It’s being driven by AI and it has an opportunity with some care and nurturing to help bring about what we think may be a much better Internet.

From Search to Answers

What’s the change? The primary discovery system of the Internet for the last 15 years has been Search Engines. They scraped the Internet’s content, built an index, and then presented users with a treasure map which they followed generating traffic. Content creators were happy to let Search Engines scrape their content because there were a limited number of them, so the infrastructure costs were relatively low and, more importantly, because the Search Engines gave something to sites in the form of traffic — the Internet’s historic currency — sent back to sites.

It’s already clear that the Internet’s discovery system for the next 15 years will be something different: Answer Engines. Unlike Search Engines which gave you a map where you hunted for what you were looking for, driving traffic in the process, Answer Engines just give you the answer without you having to click on anything. For 95 percent of users 95 percent of the time, that is a better user experience.

You don’t have to look far to see this is changing rapidly before our eyes. ChatGPT, Anthropic’s Claude, and other AI startups aren’t Search Engines — they’re Answer Engines. Even Google, the search stalwart, is increasingly serving “AI Overviews” in place of 10 blue links. We can often look to sci-fi movies to have a glimpse into our most likely future. In them, the helpful intelligent robot character didn’t answer questions with: “Here are some links you can click on to maybe find what you’re looking for.” Whether you like it or not, the future will increasingly be answers not searches.

Short Term Pain

In the short term, this is going to be extremely painful for some industries that are built based on monetizing traffic. It already is. While ecommerce and social applications haven’t yet seen a significant drop in traffic as the world switches to Answer Engines, media companies have. Why the difference? Well, for the former, you still need to buy the thing the Answer Engine recommends and, for now, we still value talking with other humans.

But for media companies, if the Answer Engine gives you the summary of what you’re looking for in most cases you don’t need to read the story. And the loss of traffic for media companies has already been dramatic. It’s not just traditional media. Research groups at investment banks, industry analysts, major consulting firms — they’re all seeing major drops in people finding their content because we are increasingly getting answers not search treasure maps.

Some say these answer engines or agents are just acting on behalf of humans. Sure but so what? Without a change they will still kill content creators’ businesses. If you ask your agent to summarize twenty different news sources but never actually visit any of them you’re still undermining the business model of those news sources. Agents don’t click on ads. And if those agents are allowed to aggregate information on behalf of multiple users it’s an even bigger problem because then subscription revenue is eliminated as well. Why subscribe to the Wall Street Journal or New York Times or Financial Times or Washington Post if my agent can free ride off some other user who does?

Unless you believe that content creators should work for free, or that they are somehow not needed anymore — both of which are naive assumptions — something needs to change. A visit from an agent isn’t the same as a visit from a human and therefore should have different rules of the road. If nothing changes, the drop in human traffic to the media ecosystem writ large will kill the business model that has built the content-rich Internet we enjoy today.

We think that’s an existential threat to one of humanity’s most important creations: the Internet.

Rewarding Better Content

But there’s reason for optimism. Content is the fuel that powers every AI system and the companies that run those AI systems know ultimately they need to financially support the ecosystem. Because of that it seems potentially we’re on the cusp of a new, better, and maybe healthier Internet business model. As content creators use tools like the ones provided by Cloudflare to restrict AI robots from taking their content without compensation, we’re already seeing a market emerge and better deals being struck between AI and content companies.

What’s most interesting is what content companies are getting the best deals. It’s not the ragebait headline writers. It’s not the news organizations writing yet another take on what’s going on in politics. It’s not the spammy content farms full of drivel. Instead, it’s Reddit and other quirky corners that best remind us of the Internet of old. For those of you old enough, think back to the Internet not of the last 15 years but of the last 35. We’ve lost some of what made that early Internet great, but there are indications that we might finally have the incentives to bring more of it back.

It seems increasingly likely that in our future, AI-driven Internet — assuming the AI companies are willing to step up, support the ecosystem, and pay for the content that is the most valuable to them — it’s the creative, local, unique, original content that’ll be worth the most. And, if you’re like us, the thing you as an Internet consumer are craving more of is creative, local, unique, original content. And, it turns out, having talked with many of them, that’s the content that content creators are most excited to create.

A New Internet Business Model

So how will the business model work? Well, for the first time in history, we have a pretty good mathematical representation of human knowledge. Sum up all the LLMs and that’s what you get. It’s not perfect, but it’s pretty good. Inherently, the same mathematical model serves as a map for the gaps in human knowledge. Like a block of Swiss Cheese — there’s a lot of cheese, but there’s also a lot of holes.

Imagine a future business model of the Internet that doesn’t reward traffic-generating ragebait but instead rewards those content creators that help fill in the holes in our collective metaphorical cheese. That will involve some portion of the subscription fees AI companies collect, and some portion of the revenue from the ads they’ll inevitably serve, going back to content creators who most enrich the collective knowledge.

As a rough and simplistic sketch, think of it as some number of dollars per AI company’s monthly active users going into a collective pool to be distributed out to content creators based on what most fills in the holes in the cheese.

You could imagine an AI company suggesting back to creators that they need more created about topics they may not have enough content about. Say, for example, the carrying capacity of unladened swallows because they know their subscribers of a certain age and proclivity are always looking for answers about that topic. The very pruning algorithms the AI companies use today form a roadmap for what content is worth enough to not be pruned but paid for.

While today the budget items that differentiate AI companies are how much they can afford to spend on GPUs and top talent, as those things inevitably become more and more commodities it seems likely what will differentiate the different AIs is their access to creative, local, unique, original content. And the math of their algorithms provides them a map of what’s worth the most. While there are a lot of details to work out, those are the ingredients you need for a healthy market.

Cloudflare’s Role

As we think about our role at Cloudflare in this developing market, it’s not about protecting the status quo but instead helping catalyze a better business model for the future of Internet content creation. That means creating a level playing field. Ideally there should be lots of AI companies, large and small, and lots of content creators, large and small.

It can’t be that a new entrant AI company is at a disadvantage to a legacy search engine because one has to pay for content but the other gets it for free. But it’s also critical to realize that the right solution to that current conundrum isn’t that no one pays, it’s that, new or old, everyone who benefits from the ecosystem should contribute back to it based on their relative size.

It may seem impossibly idealistic today, but the good news is that based on the conversations we’ve had we’re confident if a few market participants tip — whether because they step up and do the right thing or are compelled — we will see the entire market tipping and becoming robust very quickly.

Supporting the Ecosystem

We can’t do this alone and we have no plans to try to. Our mission is not to “build a better Internet” but to “help build a better Internet.” The solutions developed to facilitate this market need to be open, collaborative, standardized, and shared across many organizations. We’ll take some encouraging steps in that direction with announcements on partnerships and collaborations this week. And we’re proud to be a leader in this space.

The Internet is an ecosystem and we, other infrastructure providers, along with most importantly both AI companies and content creators, will be critical in ensuring that ecosystem is healthy. We’re excited to partner with those who are ready to step up and do their part to also help build a better Internet. It is possible.

And we’re optimistic that if others can collaborate in supporting the ecosystem we may be at the cusp of a new golden age of the Internet. Our conversations with the leading AI companies nearly all acknowledge that they have a responsibility to give back to the ecosystem and compensate content creators. Confirming this, the largest publishers are reporting they’re having much more constructive conversations about licensing their content to those AI companies. And, this week, we’ll be announcing new tools to help even the smallest publishers take back control of who can use what they’ve created.

It may seem impossible. We think it’s a no-brainer. We’re proud of what Cloudflare has accomplished over the last 15 years, but there’s a lot left to do to live up to our mission. So, more than ever, it’s clear: giddy up, because we’re just getting started!

Content Independence Day: no AI crawl without compensation!

2025-07-01 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/content-independence-day-no-ai-crawl-without-compensation/

Almost 30 years ago, two graduate students at Stanford University — Larry Page and Sergey Brin — began working on a research project they called Backrub. That, of course, was the project that resulted in Google. But also something more: it created the business model for the web.

The deal that Google made with content creators was simple: let us copy your content for search, and we’ll send you traffic. You, as a content creator, could then derive value from that traffic in one of three ways: running ads against it, selling subscriptions for it, or just getting the pleasure of knowing that someone was consuming your stuff.

Google facilitated all of this. Search generated traffic. They acquired DoubleClick and built AdSense to help content creators serve ads. And acquired Urchin to launch Google Analytics to let you measure just who was viewing your content at any given moment in time.

For nearly thirty years, that relationship was what defined the web and allowed it to flourish.

But that relationship is changing. For the first time in its history, the number of searches run on Google is declining. What’s taking its place? AI.

If you’re like me, you’ve been amazed at the new AI systems that have launched over the last two years and find yourself turning to them to answer questions that, in the past, you may have previously looked to Google. While it’s still early, it seems clear that the interface of the future of the web will look more like ChatGPT than a spartan search box and ten blue links.

Google itself has changed. While ten years ago they presented a list of links and said that success was getting you off their site as quickly as possible, today they’ve added an answer box and more recently AI Overviews which answer users’ questions without them having to leave Google.com. With the answer box they reported that 75 percent of queries were answered without users leaving Google. With the more recent launch of AI Overviews it’s even higher.

While Google’s users may like that, it’s hurting content creators. Google still copies creators’ content, but over the last 10 years, because of the changes to the UI of “search” it’s gotten almost 10 times more difficult for a content creator to get the same volume of traffic. That means it’s 10 times more difficult to generate value from ads, subscriptions, or the ego of knowing someone cares about what you created.

And that’s the good news. It’s even worse with today’s AI tools. With OpenAI, it’s 750 times more difficult to get traffic than it was with the Google of old. With Anthropic, it’s 30,000 times more difficult. The reason is simple: increasingly we aren’t consuming originals, we’re consuming derivatives.

The problem is whether you create content to sell ads, sell subscriptions, or just to know that people value what you’ve created, an AI-driven web doesn’t reward content creators the way that the old search-driven web did. And that means the deal that Google made to take content in exchange for sending you traffic just doesn’t make sense anymore.

Instead of being a fair trade, the web is being stripmined by AI crawlers with content creators seeing almost no traffic and therefore almost no value.

That changes today, July 1, what we’re calling Content Independence Day. Cloudflare, along with a majority of the world’s leading publishers and AI companies, is changing the default to block AI crawlers unless they pay creators for their content. That content is the fuel that powers AI engines, and so it’s only fair that content creators are compensated directly for it.

But that’s just the beginning. Next, we’ll work on a marketplace where content creators and AI companies, large and small, can come together. Traffic was always a poor proxy for value. We think we can do better. Let me explain.

Imagine an AI engine like a block of swiss cheese. New, original content that fills one of the holes in the AI engine’s block of cheese is more valuable than repetitive, low-value content that unfortunately dominates much of the web today.

We believe that if we can begin to score and value content not on how much traffic it generates, but on how much it furthers knowledge — measured by how much it fills the current holes in AI engines “swiss cheese” — we not only will help AI engines get better faster, but also potentially facilitate a new golden age of high-value content creation.

We don’t know all the answers yet, but we’re working with some of the leading economists and computer scientists to figure them out.

The web is changing. Its business model will change. And, in the process, we have an opportunity to learn from what was great about the web of the last 30 years and what we can make better for the web of the future.

Cloudflare’s mission is to help build a better Internet. I’m proud of the role we’re playing in doing exactly that as the web evolves. And I’m proud that we’re helping content creators stick up and demand value for the content they worked hard to create.

Happy Content Independence Day!

Cloudflare’s 2024 Annual Founders’ Letter

2024-09-22 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/cloudflare-2024-annual-founders-letter

This week Cloudflare will celebrate the fourteenth anniversary of our launch. We think of it as our birthday. As is our tradition ever since our first anniversary, we use our Birthday Week each year to launch new products that we think of as gifts back to the Internet. For the last five years, we also take this time to write our annual Founders’ Letter reflecting on our business and the state of the Internet. This year is no different.

That said, one thing that is different is you may have noticed we’ve actually had fewer public innovation weeks over the last year than usual. That’s been because a couple of incidents nearly a year ago caused us to focus on improving our internal systems over releasing new features. We’re incredibly proud of our team’s focus to make security, resilience, and reliability the top priorities for the last year. Today, Cloudflare’s underlying platform, and the products that run on top of it, are significantly more robust than ever before.

With that work largely complete, and our platform in its strongest shape ever, we plan to pick back up the usual cadence of new product launches that we’re known for. This Birthday Week, you’ll see many as we roll out performance improvements only our Connectivity Cloud can deliver to accelerate all our customers’ websites by a mind-blowing 45 percent (automatically and for free), launch new features to make our developer platform faster and easier to use, plug the web’s last encryption hole, accelerate AI inference globally, provide new levels of support for startups and the open source community, and much much more.

This is easily our favorite week of the year because of how it allows our team to give back to the Internet and live up to our mission.

Challenges for the Internet ahead

The robustness of Cloudflare’s platform today contrasts with what feels like an Internet that has become far more fragile over the previous year. When we first articulated our mission as helping build a better Internet, we assumed that “better” meant one that was faster, more reliable, more secure, more private, and more efficient. But today it seems like something more fundamental.

The last year has been characterized by a normalization of Internet shutdowns and limits on Internet access around the world. What were once tactics reserved for authoritarian regimes have spread to even Western democratic nations, where courts and legislatures have been emboldened to restrict fundamental protocols to control perceived harms.

We’ve seen a dramatic uptick in courts of limited jurisdiction ordering sites they found objectionable blocked globally at the DNS level, nations turning off the Internet for most their citizens in the name of preventing cheating on standardized tests (while it remains on in wealthy and politically connected neighborhoods), ISPs proposing legislation to impose new taxes on content creators, and whole services being banned in countries that had previously declared that more Internet was always better than less.

This is, unfortunately, a dark time in the history of the Internet.

AI’s Threat to Original Content Creation

At the same time, the business model of the web is eroding. The quid pro quo of the web’s last era — the search era — was that you let a company like Google scrape data from your website in exchange for them sending you traffic. In that model, content creators could then generate value from that traffic through ads, selling products, or just getting the ego boost of knowing that someone cares enough about the thing you created to take the time to view it.

That same quid pro quo does not hold up in the era we’re moving into — the AI era — where answers are delivered to questions without ever having to visit the authoritative source. And, if content creators can no longer generate value from their creations, it’s inevitable they’ll generate less content and we’ll all, including the AI companies that need original content to train their models, lose out as a result.

Picking Up the Mantle

The Internet remains a miracle, but it no longer feels inevitable. It is under attack from active adversaries and beginning to rot from benign neglect. And, with the largest tech companies distracted by their own regulatory challenges, it finds itself without a clear champion. We’re proud of our team for picking up that mantle. At Cloudflare, we believe in the Internet and we will fight for it.

That’s why we invest in our public policy team to educate lawmakers and jurists on how best to control the harms created by some limited corners of the Internet without destabilizing its underlying protocols. Why we believe it’s important to provide so many of our services for free. And it’s why this Birthday Week we’ll announce new ways for the AI systems that hunger for original content to compensate content creators in a way that is equitable. Without a new paradigm, we worry that the incentives that allowed the Internet to flourish will shrivel and its miracle will fade.

Missions matter. Ours it to help build a better Internet. We, or one of our senior executives, still talk to every candidate we hire before extending an offer because we want to ensure we communicate the importance of our mission. One of the most common questions we’re asked is how we plan to preserve Cloudflare’s culture? Our answer is always the same: the goal isn’t how to preserve our culture, it’s always how to improve it. The same has to be true for the Internet. We can’t just try to preserve the past, we need to imagine new ways to improve it.

That requires champions to stand up and imagine a better Internet. It’s been too long since you’ve read a positive story about the Internet even though it continues to be a miracle. We are proud that we have the team, platform, and mantle to not just preserve, but improve on, that miracle. It is our mission and what motivates everything we do at Cloudflare. And nowhere is that more on display than during the week ahead. If you too are inspired by our mission, we encourage you to apply to join our team.

Stay tuned for an incredible Birthday Week of new products that make progress on our mission. Thank you to our team around the world for everything you do. Cloudflare is stronger because of the work we’ve accomplished, and the Internet will be stronger because of Cloudflare.

Automatically replacing polyfill.io links with Cloudflare’s mirror for a safer Internet

2024-06-26 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/automatically-replacing-polyfill-io-links-with-cloudflares-mirror-for-a-safer-internet

polyfill.io, a popular JavaScript library service, can no longer be trusted and should be removed from websites.

Multiple reports, corroborated with data seen by our own client-side security system, Page Shield, have shown that the polyfill service was being used, and could be used again, to inject malicious JavaScript code into users’ browsers. This is a real threat to the Internet at large given the popularity of this library.

We have, over the last 24 hours, released an automatic JavaScript URL rewriting service that will rewrite any link to polyfill.io found in a website proxied by Cloudflare to a link to our mirror under cdnjs. This will avoid breaking site functionality while mitigating the risk of a supply chain attack.

Any website on the free plan has this feature automatically activated now. Websites on any paid plan can turn on this feature with a single click.

You can find this new feature under Security ⇒ Settings on any zone using Cloudflare.

Contrary to what is stated on the polyfill.io website, Cloudflare has never recommended the polyfill.io service or authorized their use of Cloudflare’s name on their website. We have asked them to remove the false statement and they have, so far, ignored our requests. This is yet another warning sign that they cannot be trusted.

If you are not using Cloudflare today, we still highly recommend that you remove any use of polyfill.io and/or find an alternative solution. And, while the automatic replacement function will handle most cases, the best practice is to remove polyfill.io from your projects and replace it with a secure alternative mirror like Cloudflare’s even if you are a customer.

You can do this by searching your code repositories for instances of polyfill.io and replacing it with cdnjs.cloudflare.com/polyfill/ (Cloudflare’s mirror). This is a non-breaking change as the two URLs will serve the same polyfill content. All website owners, regardless of the website using Cloudflare, should do this now.

How we came to this decision

Back in February, the domain polyfill.io, which hosts a popular JavaScript library, was sold to a new owner: Funnull, a relatively unknown company. At the time, we were concerned that this created a supply chain risk. This led us to spin up our own mirror of the polyfill.io code hosted under cdnjs, a JavaScript library repository sponsored by Cloudflare.

The new owner was unknown in the industry and did not have a track record of trust to administer a project such as polyfill.io. The concern, highlighted even by the original author, was that if they were to abuse polyfill.io by injecting additional code to the library, it could cause far reaching security problems on the Internet affecting several hundreds of thousands websites. Or it could be used to perform a targeted supply-chain attack against specific websites.

Unfortunately, that worry came true on June 25, 2024 as the polyfill.io service was being used to inject nefarious code that, under certain circumstances, redirected users to other websites.

We have taken the exceptional step of using our ability to modify HTML on the fly to replace references to the polyfill.io CDN in our customers’ websites with links to our own, safe, mirror created back in February.

In the meantime, additional threat feed providers have also taken the decision to flag the domain as malicious. We have not outright blocked the domain through any of the mechanisms we have because we are concerned it could cause widespread web outages given how broadly polyfill.io is used with some estimates indicating usage on nearly 4% of all websites.

Corroborating data with Page Shield

The original report indicates that malicious code was injected that, under certain circumstances, would redirect users to betting sites. It was doing this by loading additional JavaScript that would perform the redirect, under a set of additional domains which can be considered Indicators of Compromise (IoCs):

https://www.googie-anaiytics.com/analytics.js
https://www.googie-anaiytics.com/html/checkcachehw.js
https://www.googie-anaiytics.com/gtags.js
https://www.googie-anaiytics.com/keywords/vn-keyword.json
https://www.googie-anaiytics.com/webs-1.0.1.js
https://www.googie-anaiytics.com/analytics.js
https://www.googie-anaiytics.com/webs-1.0.2.js
https://www.googie-anaiytics.com/ga.js
https://www.googie-anaiytics.com/web-1.0.1.js
https://www.googie-anaiytics.com/web.js
https://www.googie-anaiytics.com/collect.js
https://kuurza.com/redirect?from=bitget

(note the intentional misspelling of Google Analytics)

Page Shield, our client side security solution, is available on all paid plans. When turned on, it collects information about JavaScript files loaded by end user browsers accessing your website.

By looking at the database of detected JavaScript files, we immediately found matches with the IoCs provided above starting as far back as 2024-06-08 15:23:51 (first seen timestamp on Page Shield detected JavaScript file). This was a clear indication that malicious activity was active and associated with polyfill.io.

Replacing insecure JavaScript links to polyfill.io

To achieve performant HTML rewriting, we need to make blazing-fast HTML alterations as responses stream through Cloudflare’s network. This has been made possible by leveraging ROFL (Response Overseer for FL). ROFL powers various Cloudflare products that need to alter HTML as it streams, such as Cloudflare Fonts, Email Obfuscation and Rocket Loader

ROFL is developed entirely in Rust. The memory-safety features of Rust are indispensable for ensuring protection against memory leaks while processing a staggering volume of requests, measuring in the millions per second. Rust’s compiled nature allows us to finely optimize our code for specific hardware configurations, delivering performance gains compared to interpreted languages.

The performance of ROFL allows us to rewrite HTML on-the-fly and modify the polyfill.io links quickly, safely, and efficiently. This speed helps us reduce any additional latency added by processing the HTML file.

If the feature is turned on, for any HTTP response with an HTML Content-Type, we parse all JavaScript script tag source attributes. If any are found linking to polyfill.io, we rewrite the src attribute to link to our mirror instead. We map to the correct version of the polyfill service while the query string is left untouched.

The logic will not activate if a Content Security Policy (CSP) header is found in the response. This ensures we don’t replace the link while breaking the CSP policy and therefore potentially breaking the website.

Default on for free customers, optional for everyone else

Cloudflare proxies millions of websites, and a large portion of these sites are on our free plan. Free plan customers tend to have simpler applications while not having the resources to update and react quickly to security concerns. We therefore decided to turn on the feature by default for sites on our free plan, as the likelihood of causing issues is reduced while also helping keep safe a very large portion of applications using polyfill.io.

Paid plan customers, on the other hand, have more complex applications and react quicker to security notices. We are confident that most paid customers using polyfill.io and Cloudflare will appreciate the ability to virtually patch the issue with a single click, while controlling when to do so.

All customers can turn off the feature at any time.

This isn’t the first time we’ve decided a security problem was so widespread and serious that we’d enable protection for all customers regardless of whether they were a paying customer or not. Back in 2014, we enabled Shellshock protection for everyone. In 2021, when the log4j vulnerability was disclosed we rolled out protection for all customers.

Do not use polyfill.io

If you are using Cloudflare, you can remove polyfill.io with a single click on the Cloudflare dashboard by heading over to your zone ⇒ Security ⇒ Settings. If you are a free customer, the rewrite is automatically active. This feature, we hope, will help you quickly patch the issue.

Nonetheless, you should ultimately search your code repositories for instances of polyfill.io and replace them with an alternative provider, such as Cloudflare’s secure mirror under cdnjs (https://cdnjs.cloudflare.com/polyfill/). Website owners who are not using Cloudflare should also perform these steps.

The underlying bundle links you should use are:

For minified: https://cdnjs.cloudflare.com/polyfill/v3/polyfill.min.js
For unminified: https://cdnjs.cloudflare.com/polyfill/v3/polyfill.js

Doing this ensures your website is no longer relying on polyfill.io.

Celebrating 10 years of Project Galileo

2024-06-12 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/celebrating-10-years-of-project-galileo

One of the great benefits of the Internet has been its ability to empower activists and journalists in repressive societies to organize, communicate, and simply find each other. Ten years ago today, Cloudflare launched Project Galileo, a program which today provides security services, at no cost, to more than 2,600 independent journalists and nonprofit organizations around the world supporting human rights, democracy, and local communities. You can read last week’s blog and Radar dashboard that provide a snapshot of what public interest organizations experience on a daily basis when it comes to keeping their websites online.

Origins of Project Galileo

We’ve admitted before that Project Galileo was born out of a mistake, but it’s worth reminding ourselves. In 2014, when Cloudflare was a much smaller company with a smaller network, our free service did not include DDoS mitigation. If a free customer came under a withering attack, we would stop proxying traffic to protect our own network. It just made sense.

One evening, a site that was using us came under a significant DDoS attack, exhausting Cloudflare resources. After pulling up the site and seeing Cyrillic writing and pictures of men with guns, the young engineer on call followed the playbook. He pushed a button and sent all the attack traffic to the site’s origin, effectively kicking it off the Internet.

This was in 2014, during Russia’s first invasion into Ukraine, when Russia invaded Crimea. What the engineer did not know was that he had just kicked off an independent Ukrainian newspaper that was covering the attack and the invasions. The newspaper had tried to pay for services with a credit card but failed because Russia had targeted Ukraine’s financial infrastructure, taking banking institutions offline. It wasn’t the engineer’s fault. He had no reason to know that the site was important, and no alternative playbook to follow.

After that incident, we vowed to never let an organization that was serving such an important purpose go offline simply because they couldn’t pay for services. And so the idea for Project Galileo was born.

Although the idea of providing free security services was straightforward, figuring out which organizations are important enough to deserve such services was not. We know we can’t build a better Internet alone – it’s why Cloudflare’s mission is to help build a better Internet. So with Project Galileo, we sought the assistance of a group of civil society organizations to partner with us and help identify the organizations that need our protection.

Repression of ideas that were threatening to authority hardly started with DDoS attacks or the invention of the Internet. We named the effort Project Galileo after the story of Galileo Galilei. Galileo was persecuted in the 1600s for publishing a book concluding that the Earth was not at the center of the universe, but that the Earth orbits the sun. After Galileo was labeled a heretic, his book was banned and his ideas were suppressed for more than 100 years.

Four hundred years after Galileo, we see attempts to suppress the online voices of journalists and human rights workers who might challenge the status quo. We’re proud of the fact that through Project Galileo, we keep so many of those voices online.

Growth of Project Galileo

Ten years after the launch of Project Galileo, Cloudflare has changed a lot. Our network has grown from data centers in fewer than 30 cities in 2014 to a network that runs in 320 cities and more than 120 countries. We’ve massively expanded our product suite to include whole new lines of products, including a full set of Zero Trust services and a developer suite that enables developers to build a wide range of applications, including AI applications, on our network.

As Cloudflare has grown, so has Project Galileo. We have more than quadrupled the number of entities we protect in the last five years, from 600 at Project Galileo’s five-year anniversary to more than 2,600 today, located in 111 different countries. We’ve expanded from our original 14 civil society partners to 54 today. Our partners span countries, continents, and subject matter areas, sharing their expertise on organizations that would benefit from cybersecurity assistance.

When we expand our product offerings, we routinely ask whether new services would be valuable to the journalists, humanitarian groups, and nonprofits that benefit from Project Galileo. After Cloudflare launched our Zero Trust offering, we announced that we would offer those services for free to participants in Project Galileo to protect themselves against threats like data loss and malware. After Cloudflare acquired Area 1, we announced that we would offer Cloudflare’s email security products for free to the same participants.

We’ve tried to make our products easy for a small organization to use, building a Social Impact Portal and a Zero Trust roadmap for civil society and at-risk communities. Cloudflare’s teams also help participants onboard and troubleshoot when they face challenges.

What Project Galileo means for civil society groups now

On June 6, we celebrated Project Galileo’s 10-year anniversary with partners from government, civil society, and industry at an event in Washington, DC. We used the opportunity to talk about the future of the Internet, and how we can all work together to protect and advance the free and open Internet.

For humanitarian organizations with few resources, the types of services offered under Project Galileo can be life changing. At our Project Galileo event, we heard the story of a small French nonprofit that lost 17 years of data after being targeted by ransomware. Our resources help organizations defend themselves not only against nation states determined to take them offline, but also against common ransomware and phishing attacks.

During our event, the President of the National Endowment for Democracy (NED) told the story of traveling in the Western Balkans where the struggle for an independent media is palpable. NED is a strong supporter of media outlets across the region. But those media outlets come under frequent cyber attacks that have incapacitated their websites. As described by Damon Wilson:

Those attacks prevent news from reaching the public, where information is very much something that is used and weaponized against communities across Bosnia. And this was precisely the case with one of our partners, Buka. It’s a news outlet that’s based in Banja Luka and Republika Srpska. And while I was there, I met with some of our partners from Banja Luka who had been physically beaten up and intimidated. There’s a crackdown on civil society, new restrictions and laws against them. But for Buka, it was a little bit of a different scenario because earlier this year they suffered a DDoS attack, during which their server servers were overwhelmed by up to 700 million page requests. And the sheer volume suggests the attackers had significant resources, making it a particularly severe threat.

But by onboarding Buka into Project Galileo, we were able to help them restore their site’s functionality, and now Buka’s website is equipped to withstand even the most sophisticated attacks, ensuring that their critical reporting continues uninterrupted, exactly at the time when the Republic gets Covid, Republika Srpska government is looking to close and restrict independent civic voices in that part of Bosnia.

And this is just one example. Last week, traveling in Bosnia, of the numerous NED partners who’ve benefited from Cloudflare’s Project Galileo since NED became a partner in 2019, it’s profound to the efficacy of our partners’ work. It effectively ensures that bad actors can’t silence the voices and the work of democracy advocates and independent media around the world.

The importance of collaboration

Our work with Project Galileo highlights the power of the partnerships that we’ve built, not only with civil society, but with government and industry partners as well. By working together, we can expand protections for the many at-risk organizations that need cybersecurity assistance. Cybersecurity is a team sport.

In 2023, one of our Project Galileo partners, the CyberPeace Institute, approached us about doing even more to help protect nonprofit organizations against phishing attacks. The CyberPeace Institute collaborates with its partners to reduce the harms from cyberattacks on people’s lives worldwide and provide them assistance. CyberPeace also analyzes cyberattacks to expose their societal impact, to demonstrate how international laws and norms are being violated, and to advance responsible behavior in cyberspace.

CyberPeace realized that there was an opportunity to document attacks against civil society groups and improve the ecosystem for everyone. Many development and humanitarian organizations are small, with limited staff and little cybersecurity experience. They can easily fall prey to common cyber attacks – like phishing – designed to access their systems or steal their data. If they manage to use tools effectively to defend themselves, they do not typically report on the information about the attacks they see.

CyberPeace proposed to help onboard development and humanitarian organizations to Cloudflare services through their CyberPeace Builders program and analyze the phishing campaigns targeting those organizations. The substantive insights and information gained from that work could then be fed to other civil society organizations as real time security alerts. Cloudflare worked with CyberPeace to develop the new approach, enabling their volunteers to onboard organizations in their network to Area 1 tools and their analysts to access threat indicators from the collective organizations onboarded.

Government can play an important role in helping protect civil society from cyberattacks as well. Since the Summit for Democracy last year, Cloudflare has been working closely with the Joint Cyber Defense Collaborative (JCDC), which is run by the U.S. Cybersecurity and Infrastructure Security Agency (CISA), on their High-Risk Communities initiative. Earlier this year, JCDC launched a web page outlining cybersecurity resources for civil society communities facing digital security threats because of their work. The effort includes tools and services that nonprofits can use to secure themselves online, including those offered under Project Galileo.

Expanding Cloudflare’s Impact

In many ways, the creation of Project Galileo altered the trajectory of the company. Project Galileo cemented the idea that protecting and keeping important organizations online, regardless of whether they could pay us, was part of Cloudflare’s DNA. It pushed us to innovate to improve security not only for the large enterprises that pay us, but for the small organizations doing good for the world that cannot afford to pay for the latest technological innovation. It gave us our mission – to help build a better Internet – and a standard to live up to and measure ourselves against.

To meet that standard, we routinely reach out to offer our services to important organizations in need. In 2022, after Russia’s invasion of Ukraine, Cloudflare jumped in to offer services to Ukrainian critical infrastructure facing a barrage of cyberattacks and have continued providing them services ever since. At our Project Galileo event, the State Department’s Special Envoy and Coordinator for Digital Freedom Envoy read an email she’d received from Ukraine’s Deputy Foreign Minister and Chief Digital Transformation officer of Ukraine the night before:

It is absolutely definite that Cloudflare services provide a vital layer of cybersecurity within the Ukrainian segment of cyberspace. Numerous DDoS attacks are directed at state electronic services, fintech, official information sources. So if there was no Cloudflare as a proven protection against DDoS attacks, it would have serious consequences causing chaos, especially when these attacks are synchronized by the enemy in parallel with kinetic attacks.

We’ve launched sections of Cloudflare Radar designed to use Cloudflare’s network to help civil society monitor Internet outages and disruptions, as well as route hijacks and other traffic anomalies. We’ve participated in the Freedom Online Coalition’s Task Force on Internet Shutdowns.

Project Galileo also helped pave the way for a variety of Cloudflare projects to provide other at-risk populations free services. These programs include:

Athenian Project: Launched in 2017, the Athenian Project is Cloudflare’s program to protect election-related domains for state and local governments so that citizens have reliable access to information on voter registration, polling places, and the reporting of election results.
Cloudflare for Campaigns: Launched in 2020, Cloudflare for Campaigns helps secure US political candidates’ election websites and internal data while also ensuring site reliability during peak traffic periods. The program is run in partnership with Defending Digital Campaigns.
Project Pangea: Launched in 2021, Project Pangea is a program to provide secure, performant and reliable access to the Internet for community networks that support underserved communities.
Project Safekeeping: Launched in 2022, Project Safekeeping supports at-risk critical infrastructure entities in Australia, Japan, Germany, Portugal, and the UK by providing Zero Trust and application security solutions.
Project Cybersafe Schools: Launched in 2023, Project Cybersafe Schools equips small public school districts in the US with Zero Trust services, including email protection and DNS filtering.
Project Secure Health: Launched on June 10, 2024, Project Secure Health provides security tools to Australia’s general practitioner clinics to safeguard patient data and counter challenges such as data breaches, ransomware attacks, phishing scams, and insider threats.

Looking forward

The world has only gotten more complicated since we first launched Project Galileo in 2014. We face real challenges ranging from malicious cyber actors targeting critical infrastructure, to election interference, to data theft. Governments have responded with increasingly aggressive attempts to control aspects of the Internet. At our recent celebration of Project Galileo, we lamented the thirteenth consecutive year of decline of global Internet freedom, as documented by our Project Galileo partner Freedom House.

But one thing has not changed. We continue to believe the single, global Internet is a miracle that we should all be fighting for. We sometimes forget that the Internet is an incredibly radical concept. The world somehow came together over the last 40 years, agreed on a set of standards, and then made it so that a collection of networks could all exchange data. And that miracle that is the Internet has brought incredible opportunities for the voices of civil society to be heard, to help extend their impact, to spread their message, and to keep them connected.

Connecting everyone online in a permissionless way comes with real harms and real risks. But we need to be surgical as we address those challenges. We need to partner to find solutions that preserve the open Internet, much as we do with projects like Project Galileo. Even if we are at a moment of democratic decline, continuing to defend the open, interoperable Internet preserves space and capacity for a future in which the Internet can also fuel greater freedom.

Major data center power failure (again): Cloudflare Code Orange tested

2024-04-08 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/major-data-center-power-failure-again-cloudflare-code-orange-tested

Here’s a post we never thought we’d need to write: less than five months after one of our major data centers lost power, it happened again to the exact same data center. That sucks and, if you’re thinking “why do they keep using this facility??,” I don’t blame you. We’re thinking the same thing. But, here’s the thing, while a lot may not have changed at the data center, a lot changed over those five months at Cloudflare. So, while five months ago a major data center going offline was really painful, this time it was much less so.

This is a little bit about how a high availability data center lost power for the second time in five months. But, more so, it’s the story of how our team worked to ensure that even if one of our critical data centers lost power it wouldn’t impact our customers.

On November 2, 2023, one of our critical facilities in the Portland, Oregon region lost power for an extended period of time. It happened because of a cascading series of faults that appears to have been caused by maintenance by the electrical grid provider, climaxing with a ground fault at the facility, and was made worse by a series of unfortunate incidents that prevented the facility from getting back online in a timely fashion.

If you want to read all the gory details, they’re available here.

It’s painful whenever a data center has a complete loss of power, but it’s something that we were supposed to expect. Unfortunately, in spite of that expectation, we hadn’t enforced a number of requirements on our products that would ensure they continued running in spite of a major failure.

That was a mistake we were never going to allow to happen again.

Code Orange

The incident was painful enough that we declared what we called Code Orange. We borrowed the idea from Google which, when they have an existential threat to their business, reportedly declares a Code Yellow or Code Red. Our logo is orange, so we altered the formula a bit.

Our conception of Code Orange was that the person who led the incident, in this case our SVP of Technical Operations, Jeremy Hartman, would be empowered to charge any engineer on our team to work on what he deemed the highest priority project. (Unless we declared a Code Red, which we actually ended up doing due to a hacking incident, and which would then take even higher priority. If you’re interested, you can read more about that here.)

After getting through the immediate incident, Jeremy quickly triaged the most important work that needed to be done in order to ensure we’d be highly available even in the case of another catastrophic failure of a major data center facility. And the team got to work.

How’d we do?

We didn’t expect such an extensive real-world test so quickly, but the universe works in mysterious ways. On Tuesday, March 26, 2024, — just shy of five months after the initial incident — the same facility had another major power outage. Below, we’ll get into what caused the outage this time, but what is most important is that it provided a perfect test for the work our team had done under Code Orange. So, what were the results?

First, let’s revisit what functions the Portland data centers at Cloudflare provide. As described in the November 2, 2023, post, the control plane of Cloudflare primarily consists of the customer-facing interface for all of our services including our website and API. Additionally, the underlying services that provide the Analytics and Logging pipelines are primarily served from these facilities.

Just like in November 2023, we were alerted immediately that we had lost connectivity to our PDX01 data center. Unlike in November, we very quickly knew with certainty that we had once again lost all power, putting us in the exact same situation as five months prior. We also knew, based on a successful internal cut test in February, how our systems should react. We had spent months preparing, updating countless systems and activating huge amounts of network and server capacity, culminating with a test to prove the work was having the intended effect, which in this case was an automatic failover to the redundant facilities.

Our Control Plane consists of hundreds of internal services, and the expectation is that when we lose one of the three critical data centers in Portland, these services continue to operate normally in the remaining two facilities, and we continue to operate primarily in Portland. We have the capability to fail over to our European data centers in case our Portland centers are completely unavailable. However, that is a secondary option, and not something we pursue immediately.

On March 26, 2024, at 14:58 UTC, PDX01 lost power and our systems began to react. By 15:05 UTC, our APIs and Dashboards were operating normally, all without human intervention. Our primary focus over the past few months has been to make sure that our customers would still be able to configure and operate their Cloudflare services in case of a similar outage. There were a few specific services that required human intervention and therefore took a bit longer to recover, however the primary interface mechanism was operating as expected.

To put a finer point on this, during the November 2, 2023, incident the following services had at least six hours of control plane downtime, with several of them functionally degraded for days.

API and Dashboard
Zero Trust
Magic Transit
SSL
SSL for SaaS
Workers
KV
Waiting Room
Load Balancing
Zero Trust Gateway
Access
Pages
Stream
Images

During the March 26, 2024, incident, all of these services were up and running within minutes of the power failure, and many of them did not experience any impact at all during the failover.

The data plane, which handles the traffic that Cloudflare customers pass through our 300+ data centers, was not impacted.

Our Analytics platform, which provides a view into customer traffic, was impacted and wasn’t fully restored until later that day. This was expected behavior as the Analytics platform is reliant on the PDX01 data center. Just like the Control Plane work, we began building new Analytics capacity immediately after the November 2, 2023, incident. However, the scale of the work requires that it will take a bit more time to complete. We have been working as fast as we can to remove this dependency, and we expect to complete this work in the near future.

Once we had validated the functionality of our Control Plane services, we were faced yet again with the cold start of a very large data center. This activity took roughly 72 hours in November 2023, but this time around we were able to complete this in roughly 10 hours. There is still work to be done to make that even faster in the future, and we will continue to refine our procedures in case we have a similar incident in the future.

How did we get here?

As mentioned above, the power outage event from last November led us to introduce Code Orange, a process where we shift most or all engineering resources to addressing the issue at hand when there’s a significant event or crisis. Over the past five months, we shifted all non-critical engineering functions to focusing on ensuring high reliability of our control plane.

Teams across our engineering departments rallied to ensure our systems would be more resilient in the face of a similar failure in the future. Though the March 26, 2024, incident was unexpected, it was something we’d been preparing for.

The most obvious difference is the speed at which the control plane and APIs regained service. Without human intervention, the ability to log in and make changes to Cloudflare configuration was possible seven minutes after PDX01 was lost. This is due to our efforts to move all of our configuration databases to a Highly Available (HA) topology, and pre-provision enough capacity that we could absorb the capacity loss. More than 100 databases across over 20 different database clusters simultaneously failed out of the affected facility and restored service automatically. This was actually the culmination of over a year’s worth of work, and we make sure we prove our ability to failover properly with weekly tests.

Another significant improvement is the updates to our Logpush infrastructure. In November 2023, the loss of the PDX01 datacenter meant that we were unable to push logs to our customers. During Code Orange, we invested in making the Logpush infrastructure HA in Portland, and additionally created an active failover option in Amsterdam. Logpush took advantage of our massively expanded Kubernetes cluster that spans all of our Portland facilities and provides a seamless way for service owners to deploy HA compliant services that have resiliency baked in. In fact, during our February chaos exercise, we found a flaw in our Portland HA deployment, but customers were not impacted because the Amsterdam Logpush infrastructure took over successfully. During this event, we saw that the fixes we’d made since then worked, and we were able to push logs from the Portland region.

A number of other improvements in our Stream and Zero Trust products resulted in little to no impact to their operation. Our Stream products, which use a lot of compute resources to transcode videos, were able to seamlessly hand off to our Amsterdam facility to continue operations. Teams were given specific availability targets for the services and were provided several options to achieve those targets. Stream is a good example of a service that chose a different resiliency architecture but was able to seamlessly deliver their service during this outage. Zero Trust, which was also impacted in November 2023, has since moved the vast majority of its functionally to our hundreds of data centers, which kept working seamlessly throughout this event. Ultimately this is the strategy we are pushing all Cloudflare products to adopt as our 300+ data centers provide the highest level of availability possible.

What happened to the power in the data center?

On March 26, 2024, at 14:58 UTC, PDX01 experienced a total loss of power to Cloudflare’s physical infrastructure following a reportedly simultaneous failure of four Flexential-owned and operated switchboards serving all of Cloudflare’s cages. This meant both primary and redundant power paths were deactivated across the entire environment. During the Flexential investigation, engineers focused on a set of equipment known as Circuit Switch Boards, or CSBs. CSBs are likened to an electrical panel board, consisting of a main input circuit breaker and series of smaller output breakers. Flexential engineers reported that infrastructure upstream of the CSBs (power feed, generator, UPS & PDU/transformer) was not impacted and continued to act normally. Similarly, infrastructure downstream from the CSBs such as Remote Power Panels and connected switchgear was not impacted – thus implying the outage was isolated to the CSBs themselves.

Initial assessment of the root cause of Flexential’s CSB failures points to incorrectly set breaker coordination settings within the four CSBs as one contributing factor. Trip settings which are too restrictive can result in overly sensitive overcurrent protection and the potential nuisance tripping of devices. In our case, Flexential’s breaker settings within the four CSBs were reportedly too low in relation to the downstream provisioned power capacities. When one or more of these breakers tripped, a cascading failure of the remaining active CSB boards resulted, thus causing a total loss of power serving Cloudflare’s cage and others on the shared infrastructure. During the triage of the incident, we were told that the Flexential facilities team noticed the incorrect trip settings, reset the CSBs and adjusted them to the expected values, enabling our team to power up our servers in a staged and controlled fashion. We do not know when these settings were established – typically, these would be set/adjusted as part of a data center commissioning process and/or breaker coordination study before customer critical loads are installed.

What’s next?

Our top priority is completing the resilience program for our Analytics platform. Analytics aren’t simply pretty charts in a dashboard. When you want to check the status of attacks, activities a firewall is blocking, or even the status of Cloudflare Tunnels – you need analytics. We have evidence that the resiliency pattern we are adopting works as expected, so this remains our primary focus, and we will progress as quickly as possible.

There were some services that still required manual intervention to properly recover, and we have collected data and action items for each of them to ensure that further manual action is not required. We will continue to use production cut tests to prove all of these changes and enhancements provide the resiliency that our customers expect.

We will continue to work with Flexential on follow-up activities to expand our understanding of their operational and review procedures to the greatest extent possible. While this incident was limited to a single facility, we will turn this exercise into a process that ensures we have a similar view into all of our critical data center facilities.

Once again, we are very sorry for the impact to our customers, particularly those that rely on the Analytics engine who were unable to access that product feature during the incident. Our work over the past four months has yielded the results that we expected, and we will stay absolutely focused on completing the remaining body of work.

Post Mortem on Cloudflare Control Plane and Analytics Outage

2023-11-04 Matthew Prince

Post Syndicated from Matthew Prince original http://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/

Beginning on Thursday, November 2, 2023 at 11:43 UTC Cloudflare’s control plane and analytics services experienced an outage. The control plane of Cloudflare consists primarily of the customer-facing interface for all of our services including our website and APIs. Our analytics services include logging and analytics reporting.

The incident lasted from November 2 at 11:44 UTC until November 4 at 04:25 UTC. We were able to restore most of our control plane at our disaster recovery facility as of November 2 at 17:57 UTC. Many customers would not have experienced issues with most of our products after the disaster recovery facility came online. However, other services took longer to restore and customers that used them may have seen issues until we fully resolved the incident. Our raw log services were unavailable for most customers for the duration of the incident.

Services have now been restored for all customers. Throughout the incident, Cloudflare’s network and security services continued to work as expected. While there were periods where customers were unable to make changes to those services, traffic through our network was not impacted.

This post outlines the events that caused this incident, the architecture we had in place to prevent issues like this, what failed, what worked and why, and the changes we’re making based on what we’ve learned over the last 36 hours.

To start, this never should have happened. We believed that we had high availability systems in place that should have stopped an outage like this, even when one of our core data center providers failed catastrophically. And, while many systems did remain online as designed, some critical systems had non-obvious dependencies that made them unavailable. I am sorry and embarrassed for this incident and the pain that it caused our customers and our team.

Intended Design

Cloudflare’s control plane and analytics systems run primarily on servers in three data centers around Hillsboro, Oregon. The three data centers are independent of one another, each have multiple utility power feeds, and each have multiple redundant and independent network connections.

The facilities were intentionally chosen to be at a distance apart that would minimize the chances that a natural disaster would cause all three to be impacted, while still close enough that they could all run active-active redundant data clusters. This means that they are continuously syncing data between the three facilities. By design, if any of the facilities goes offline then the remaining ones are able to continue to operate.

This is a system design that we began implementing four years ago. While most of our critical control plane systems had been migrated to the high availability cluster, some services, especially for some newer products, had not yet been added to the high availability cluster.

In addition, our logging systems were intentionally not part of the high availability cluster. The logic of that decision was that logging was already a distributed problem where logs were queued at the edge of our network and then sent back to the core in Oregon (or another regional facility for customers using regional services for logging). If our logging facility was offline then analytics logs would queue at the edge of our network until it came back online. We determined that analytics being delayed was acceptable.

Flexential Data Center Power Failure

The largest of the three facilities in Oregon is run by Flexential. We refer to this facility as “PDX-04.” Cloudflare leases space in PDX-04 where we house our largest analytics cluster as well as more than a third of the machines for our high availability cluster. It is also the default location for services that have not yet been onboarded onto our high availability cluster. We are a relatively large customer of the facility, consuming approximately 10 percent of its total capacity.

On November 2 at 08:50 UTC Portland General Electric (PGE), the utility company that services PDX-04, had an unplanned maintenance event affecting one of their independent power feeds into the building. That event shut down one feed into PDX-04. The data center has multiple feeds with some level of independence that can power the facility. However, Flexential powered up their generators to effectively supplement the feed that was down.

Counter to best practices, Flexential did not inform Cloudflare that they had failed over to generator power. None of our observability tools were able to detect that the source of power had changed. Had they informed us, we would have stood up a team to monitor the facility closely and move control plane services that were dependent on that facility out while it was degraded.

It is also unusual that Flexential ran both the one remaining utility feed and the generators at the same time. It is not unusual for utilities to ask data centers to drop off the grid when power demands are high and run exclusively on generators. Flexential operates 10 generators, inclusive of redundant units, capable of supporting the facility at full load. It would also have been possible for Flexential to run the facility only from the remaining utility feed. We haven’t gotten a clear answer why they ran utility power and generator power.

Informed Speculation On What Happened Next

From this decision onward, we don’t yet have clarity from Flexential on the root cause or some of the decisions they made or the events. We will update this post as we get more information from Flexential, as well as PGE, on what happened. Some of what follows is informed speculation based on the most likely series of events as well as what individual Flexential employees have shared with us unofficially.

One possible reason they may have left the utility line running is because Flexential was part of a program with PGE called DSG. DSG allows the local utility to run a data center’s generators to help supply additional power to the grid. In exchange, the power company helps maintain the generators and supplies fuel. We have been unable to locate any record of Flexential informing us about the DSG program. We’ve asked if DSG was active at the time and have not received an answer. We do not know if it contributed to the decisions that Flexential made, but it could explain why the utility line continued to remain online after the generators were started.

At approximately 11:40 UTC, there was a ground fault on a PGE transformer at PDX-04. We believe, but have not been able to get confirmation from Flexential or PGE, that this was the transformer that stepped down power from the grid for the second feed that was still running as it entered the data center. It seems likely, though we have not been able to confirm with Flexential or PGE, that the ground fault was caused by the unplanned maintenance PGE was performing that impacted the first feed. Or it was a very unlucky coincidence.

Ground faults with high voltage (12,470 volt) power lines are very bad. Electrical systems are designed to quickly shut down to prevent damage when one occurs. Unfortunately, in this case, the protective measure also shut down all of PDX-04’s generators. This meant that the two sources of power generation for the facility — both the redundant utility lines as well as the 10 generators — were offline.

Fortunately, in addition to the generators, PDX-04 also contains a bank of UPS batteries. These batteries are supposedly sufficient to power the facility for approximately 10 minutes. That time is meant to be enough to bridge the gap between the power going out and the generators automatically starting up. If Flexential could get the generators or a utility feed restored within 10 minutes then there would be no interruption. In reality, the batteries started to fail after only 4 minutes based on what we observed from our own equipment failing. And it took Flexential far longer than 10 minutes to get the generators restored.

Attempting to Restore Power

While we haven’t gotten official confirmation, we have been told by employees that three things hampered getting the generators back online. First, they needed to be physically accessed and manually restarted because of the way the ground fault had tripped circuits. Second, Flexential’s access control system was not powered by the battery backups so it was offline. And third, the overnight staffing at the site did not include an experienced operations or electrical expert — the overnight shift consisted of security and an unaccompanied technician who had only been on the job for a week.

Between 11:44 and 12:01 UTC, with the generators not fully restarted, the UPS batteries ran out of power and all customers of the data center lost power. Throughout this, Flexential never informed Cloudflare that there was any issue at the facility. We were first notified of issues in the data center when the two routers that connect the facility to the rest of the world went offline at 11:44 UTC. When we weren’t able to reach the routers directly or through out-of-band management, we attempted to contact Flexential and dispatched our local team to physically travel to the facility. The first message to us from Flexential that they were experiencing an issue was at 12:28 UTC.

We are currently experiencing an issue with power at our [PDX-04] that began at approximately 0500AM PT [12:00 UTC]. Engineers are actively working to resolve the issue and restore service. We will communicate progress every 30 minutes or as more information becomes available as to the estimated time to restore. Thank you for your patience and understanding.

Designing for Data Center Level Failure

While the PDX-04’s design was certified Tier III before construction and is expected to provide high availability SLAs, we planned for the possibility that it could go offline. Even well-run facilities can have bad days. And we planned for that. What we expected would happen in that case is that our analytics would be offline, logs would be queued at the edge and delayed, and certain lower priority services that were not integrated into our high availability cluster would go offline temporarily until they could be restored at another facility.

The other two data centers running in the area would take over responsibility for the high availability cluster and keep critical services online. Generally that worked as planned. Unfortunately, we discovered that a subset of services that were supposed to be on the high availability cluster had dependencies on services exclusively running in PDX-04.

In particular, two critical services that process logs and power our analytics — Kafka and ClickHouse — were only available in PDX-04 but had services that depended on them that were running in the high availability cluster. Those dependencies shouldn’t have been so tight, should have failed more gracefully, and we should have caught them.

We had performed testing of our high availability cluster by taking offline each (and both) of the other two data center facilities entirely offline. And we had also tested taking the high availability portion of PDX-04 offline. However, we had never tested fully taking the entire PDX-04 facility offline. As a result, we had missed the importance of some of these dependencies on our data plane.

We were also far too lax about requiring new products and their associated databases to integrate with the high availability cluster. Cloudflare allows multiple teams to innovate quickly. As such, products often take different paths toward their initial alpha. While, over time, our practice is to migrate the backend for these services to our best practices, we did not formally require that before products were declared generally available (GA). That was a mistake as it meant that the redundancy protections we had in place worked inconsistently depending on the product.

Moreover, far too many of our services depend on the availability of our core facilities. While this is the way a lot of software services are created, it does not play to Cloudflare’s strength. We are good at distributed systems. Throughout this incident, our global network continued to perform as expected. While some of our products and features are configurable and serviceable through the edge of our network without needing the core, far too many today fail if the core is unavailable. We need to use the distributed systems products that we make available to all our customers for all our services so they continue to function mostly as normal even if our core facilities are disrupted.

Disaster Recovery

At 12:48 UTC, Flexential was able to get the generators restarted. Power returned to portions of the facility. In order to not overwhelm the system, when power is restored to a data center it is typically done gradually by powering back on one circuit at a time. Like the circuit breakers in a residential home, each customer is serviced by redundant breakers. When Flexential attempted to power back up Cloudflare’s circuits, the circuit breakers were discovered to be faulty. We don’t know if the breakers failed due to the ground fault or some other surge as a result of the incident, or if they’d been bad before and it was only discovered after they had been powered off.

Flexential began the process of replacing the failed breakers. That required them to source new breakers because more were bad than they had on hand in the facility. Because more services were offline than we expected, and because Flexential could not give us a time for restoration of our services, we made the call at 13:40 UTC to fail over to Cloudflare’s disaster recovery sites located in Europe. Thankfully, we only needed to fail over a small percentage of Cloudflare’s overall control plane. Most of our services continued to run across our high availability systems across the two active core data centers.

We turned up the first services on the disaster recovery site at 13:43 UTC.Cloudflare’s disaster recovery sites provide critical control plane services in the event of a disaster. While the disaster recovery site does not support some of our log processing services, it is designed to support the other portions of our control plane.

When services were turned up there, we experienced a thundering herd problem where the API calls that had been failing overwhelmed our services. We implemented rate limits to get the request volume under control. During this period, customers of most products would have seen intermittent errors when making modifications through our dashboard or API. By 17:57 UTC, the services that had been successfully moved to the disaster recovery site were stable and most customers were no longer directly impacted. However, some systems still required manual configuration (e.g., Magic WAN) and some other services, largely related to log processing and some bespoke APIs, remained unavailable until we were able to restore PDX-04.

Some Products and Features Delayed Restart

A handful of products did not properly get stood up on our disaster recovery sites. These tended to be newer products where we had not fully implemented and tested a disaster recovery procedure. These included our Stream service for uploading new videos and some other services. Our team worked two simultaneous tracks to get these services restored: 1) reimplementing them on our disaster recovery sites; and 2) migrating them to our high-availability cluster.

Flexential replaced our failed circuit breakers, restored both utility feeds, and confirmed clean power at 22:48 UTC. Our team was all-hands-on-deck and had worked all day on the emergency, so I made the call that most of us should get some rest and start the move back to PDX-04 in the morning. That decision delayed our full recovery, but I believe made it less likely that we’d compound this situation with additional mistakes.

Beginning first thing on November 3, our team began restoring service in PDX-04. That began with physically booting our network gear then powering up thousands of servers and restoring their services. The state of our services in the data center was unknown as we believed multiple power cycles were likely to have occurred during the incident. Our only safe process to recover was to follow a complete bootstrap of the entire facility.

This involved a manual process of bringing our configuration management servers online to begin the restoration of the facility. Rebuilding these took 3 hours. From there, our team was able to bootstrap the rebuild of the rest of the servers that power our services. Each server took between 10 minutes and 2 hours to rebuild. While we were able to run this in parallel across multiple servers, there were inherent dependencies between services that required some to be brought back online in sequence.

Services are now fully restored as of November 4 at 04:25 UTC. For most customers, because of how we queue analytics at the edge, you should see no data loss in your analytics. Any gaps that appear as of now we expect will fill in as any lingering caches of analytics data is ingested. For customers that use our log push feature, your logs will not have been processed for the majority of the event, so anything you did not receive will not be recovered. However, the records in our analytics dashboard will still be accurate.

Lessons and Remediation

We have a number of questions that we need answered from Flexential. But we also must expect that entire data centers may fail. Google has a process where when there’s a significant event or crisis they can call a Code Yellow or Code Red. In these cases, most or all engineering resources are shifted to addressing the issue at hand.

We have not had such a process in the past, but it’s clear today we need to implement a version of it ourselves: Code Orange. We are shifting all non-critical engineering functions to focusing on ensuring high reliability of our control plane. As part of that, we expect the following changes:

Remove dependencies on our core data centers for control plane configuration of all services and move them wherever possible to be powered first by our distributed network
Ensure that the control plane running on the network continues to function even if all our core data centers are offline
Require that all products and features that are designated Generally Available must rely on the high availability cluster (if they rely on any of our core data centers), without having any software dependencies on specific facilities
Require all products and features that are designated Generally Available have a reliable disaster recovery plan that is tested
Test the blast radius of system failures and minimize the number of services that are impacted by a failure
Implement more rigorous chaos testing of all data center functions including the full removal of each of our core data center facilities
Thorough auditing of all core data centers and a plan to reaudit to ensure they comply with our standards
Logging and analytics disaster recovery plan that ensures no logs are dropped even in the case of a failure of all our core facilities

As I said earlier, I am sorry and embarrassed for this incident and the pain that it caused our customers and our team. We have the right systems and procedures in place to be able to withstand even the cascading string of failures we saw at our data center provider, but we need to be more rigorous about enforcing that they are followed and tested for unknown dependencies. This will have my full attention and the attention of a large portion of our team through the balance of the year. And the pain from the last couple days will make us better.

Cloudflare’s 2023 Annual Founders’ Letter

2023-09-27 Matthew Prince

Post Syndicated from Matthew Prince original http://blog.cloudflare.com/cloudflares-annual-founders-letter-2023/

Cloudflare’s 2023 Annual Founders’ Letter

Cloudflare is officially a teenager. We launched on September 27, 2010. Today we celebrate our thirteenth birthday. As is our tradition, we use the week of our birthday to launch products that we think of as our gift back to the Internet. More on some of the incredible announcements in a second, but we wanted to start by talking about something more fundamental: our identity.

Like many kids, it took us a while to fully understand who we are. We chafed at being put in boxes. People would describe Cloudflare as a security company, and we'd say, "That's not all we do." They'd say we were a network, and we'd object that we were so much more. Worst of all, they'd sometimes call us a "CDN," and we'd remind them that caching is a part of any sensibly designed system, but it shouldn't be a feature unto itself. Thank you very much.

And so, yesterday, the day before our thirteenth birthday, we announced to the world finally what we realized we are: a connectivity cloud.

The connectivity cloud

What does that mean? "Connectivity" means we measure ourselves by connecting people and things together. Our job isn't to be the final destination for your data, but to help it move and flow. Any application, any data, anyone, anywhere, anytime — that's the essence of connectivity, and that’s always been the promise of the Internet.

"Cloud" means the batteries are included. It scales with you. It’s programmable. Has consistent security built in. It’s intelligent and learns from your usage and others' and optimizes for outcomes better than you ever could on your own.

Our connectivity cloud is worth contrasting against some other clouds. The so-called hyperscale public clouds are, in many ways, the opposite. They optimize for hoarding your data. Locking it in. Making it difficult to move. They are captivity clouds. And, while they may be great for some things, their full potential will only truly be unlocked for customers when combined with a connectivity cloud that lets you mix and match the best of each of their features.

Enabling the future

That's what we're seeing from the hottest startups these days. Many of the leading AI companies are using Cloudflare's connectivity cloud to move their training data to wherever there's excess GPU capacity. We estimate that across the AI startup ecosystem, Cloudflare is the most commonly used cloud provider. Because, if you're building the future, you know connectivity and the agility of the cloud are key.

We've spent the last year listening to our AI customers and trying to understand what the future of AI will look like and how we can better help them build it. Today, we're releasing a series of products and features borne of those conversations and opening incredible new opportunities.

The biggest opportunity in AI is inference. Inference is what happens when you type a prompt to write a poem about your love of connectivity clouds into ChatGPT and, seconds later, get a coherent response. Or when you run a search for a picture of your passport on your phone, and it immediately pulls it up.

The models that power those modern miracles take significant time to generate — a process called training. Once trained though, they can have new data fed through them over and over to generate valuable new output.

Where inference happens

Before today, those models could run in two places. The first was the end user's device — like in the case of the search for “passport” in the photos on your phone. When that's possible it's great. It's fast. Your private data stays local. And it works even when there's no network access. But it's also challenging. Models are big and the storage on your phone or other local device is limited. Moreover, putting the fastest GPU resources to process these models in your phone makes the phone expensive and burns precious battery resources.

The alternative has been the centralized public cloud. This is what’s used for a big model like OpenAI’s GPT-4, which runs services like ChatGPT. But that has its own challenges. Today, nearly all the GPU resources for AI are deployed in the US — a fact that rightfully troubles the rest of the world. As AI queries get more personal, sending them all to some centralized cloud is a potential security and data locality disaster waiting to happen. Moreover, it's inherently slow and less efficient and therefore more costly than running the inference locally.

A third place for inference

Running on the device is too small. Running on the centralized public cloud is too far. It’s like the story of “Goldilocks and the Three Bears”: the right answer is somewhere in between. That's why today we're excited to be rolling out modern GPU resources across Cloudflare's global connectivity cloud. The third place for AI inference. Not too small. Not too far. The perfect step in between. By the end of the year, you'll be able to run AI models in more than 100 cities in 40+ countries where Cloudflare operates. By the end of 2024, we plan to have inference-tuned GPUs deployed in nearly every city that makes up Cloudflare's global network and within milliseconds of nearly every device connected to the Internet worldwide.

(A brief shout out for the Cloudflare team members who are, as of this moment, literally dragging suitcases full of NVIDIA GPU cards around the world and installing them in the servers that make up our network worldwide. It takes a lot of atoms to move all the bits that we do, and it takes intrepid people spanning the globe to update our network to facilitate these new capabilities.)

Running AI in a connectivity cloud like Cloudflare gives you the best of both worlds: nearly boundless resources running locally near any device connected to the Internet. And we've made it flexible to run whatever models a developer creates, easy to use without needing a dev ops team, and inexpensive to run where you only pay for when we're doing inference work for you.

To make this tangible, think about a Cloudflare customer like Garmin. They make devices that need to be smart but also affordable and have the longest possible battery life. As explorers rely on them literally to navigate out of harrowing conditions, tradeoffs aren't an option. That's why, when they heard about Cloudflare Workers AI, they immediately knew it was something they needed to try. Here's what Aaron Dearinger, Edge Architect at Garmin International said to us:

"Garmin is alongside our users for all their runs, workouts, and outdoor adventures, and we want to ensure that our watches and devices' power can last weeks and months instead of hours or days. We're excited for Cloudflare's innovations to ensure AI is performant, fast, close to users, and importantly privacy-first. This holds a lot of potential to us as we aim to bring more advanced fitness, wellness, and adventure insights to our users as they explore."

They are one of the limited set of customers we gave an early sneak peek to, all of whom immediately started running off ideas of what they could do next and clamoring to get more access. We feel like we’ve seen it and are here to report: the not-so-distant future is super cool.

The spirit of helping build a better Internet

Over the years we've announced several things on our birthday that have gone on to change the future of the Internet. On our first birthday, we announced an IPv6 gateway that has helped the Internet scale past its early protocol decisions. On our fourth birthday, we announced that we were making encryption free and doubled the size of the encrypted web in a day. On our seventh birthday, we launched the Workers platform that has revolutionized how modern applications are developed. On our eleventh birthday we announced R2 and further freed data from the captivity clouds.

This year, as we celebrate Cloudflare's thirteenth birthday, we set out to have as dramatic an impact on AI development as we have in other areas we've focused on in the past: providing tools that bring affordable, powerful AI inference to anyone, anywhere on Earth.

Closing with a poem

And so, to commemorate that, let's close with a poem about the connectivity cloud. This one was generated using a tiny bit of code and Meta's Llama 2 LLM model running on Cloudflare's Workers AI platform in a data center not far from where we're writing this…

Prompt: “Write a poem that talks about the connectivity cloud and contrast it with the captivity cloud”

The connectivity cloud, a wondrous sight to see,
Where data flows and knowledge is set free,
A place where minds meet and ideas take flight,
A world of endless possibility in sight.

But then there's the captivity cloud, a darker place,
Where thoughts are trapped and minds are in disgrace,
A prison of the mind, where freedom's lost,
A world of endless sorrow and cost.

So let us choose the connectivity cloud,
And let our minds be free and allowed,
To soar and glide and reach for the sky,
And never be held back, but always fly.

Welcome to Cloudflare’s Impact Week

2022-12-11 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/welcome-to-cloudflares-impact-week/

Welcome to Cloudflare’s Impact Week

In the early days of Cloudflare, we made it a policy that every new hire had to interview with either me or my co-founder Michelle. It’s still the case today, though we now have more than 3,000 employees, continue to hire great people as we find them, and, because there are only so many hours in the day, have had to enlist a few more senior executives to help with these final calls.

At first, these calls were about helping screen for new members of our small team. But, as our team grew, the purpose of these calls changed. Today, by the time I do the final call with someone we’ve made the decision to hire them, so it’s rarely about screening. Instead, the primary purpose is to make sure everyone joining has had a positive conversation with a senior member of our team, so if in the future they ever see something going wrong they’ll hopefully feel a bit more comfortable letting one of us know. I think because of that these calls are some of the most important work I do.

But, for me, there’s another purpose. I get to hear first-hand why people chose to apply. That’s a barometer for what we’re doing right, evaluated by someone with a perspective outside the organization. And, nearly every day, I hear some version of the same thing: the most consistent reason new employees want to join Cloudflare is because of our mission and the breadth of our impact.

Our team wants the work they do to have a real, positive impact for the millions of users of our services and the billions of Internet users our decisions affect downstream. It makes me smile every time someone we’re about to extend an offer to says something along the lines of “when Cloudflare pushes a new feature or product, you’re changing the entire Internet for the better. And I want to be part of that.” That’s why I continue to be excited about my job too.

It may seem like our mission to “help build a better Internet” has been around forever, but it wasn’t something we had at the beginning. It developed as the natural outgrowth of the team we assembled and the products we built. Today, it’s integral to Cloudflare’s DNA. Our team has always been optimistic about the Internet and its potential to do good, especially if it is founded on respect for certain values like security, privacy, interoperability, and wide availability.

That’s why the focus on privacy over the past few years was always easy for us. We never sold customer data to marketers — that just didn’t seem like what would be a part of a better Internet — so when it came time to comply with new privacy laws, we didn’t have to pull back operations or cut off lines of revenue. Instead, we rolled out the use of Universal SSL to expand encryption broadly for the Internet, and we created our first consumer-facing product, a privacy-first DNS resolver.

As we kick off this year’s Impact Week, we certainly see a number of challenges for the Internet, though we think the opportunities for the Internet continue to far outweigh those challenges. Around the world, we see a number of countries rejecting the opportunity to maximize the potential of the Internet, and instead, passing new laws and regulations seeking to assert narrow control of the Internet for their own self-interested purposes, including in some cases for things like commercial advantage, censorship, or surveillance.

For example, around the Russian invasion of Ukraine, we’ve seen the Russian government launch cyberattacks and use targeted Internet outages to further torment the people in Ukraine, while at the same time pressing citizens in Russia to only use Internet tools and view information controlled by the Russian government.

Yet for all those challenges, we saw a disparate group of people and companies, including Cloudflare, come together to defend Ukraine from these attacks and do everything in their power to get the Internet back online as soon as possible. Nearly a year into the war, and despite the relentless efforts of a very powerful nation, the Internet remains a positive force for good in Ukraine, a way for them to get the message out about the horrific actions of the Russian government, and a tool for dissidents inside Russia to escape the attempted grip of censorship. When Russia personally sanctioned me earlier this year I took it as a badge of honor we were doing something right.

At the same time, the promise of the Internet continues to bring increased opportunity, especially in still developing parts of the world. Increased access to reliable and secure Internet in those countries will enable education, healthcare, and commerce in ways humanity has been struggling to advance for decades.

And we’ve seen recently in Iran that the Internet remains the leading tool for liberation for oppressed voices who seek to shake the control of authoritarian governments. This led to the somewhat unusual step by the US government of relaxing some of the sanctions against Iran in order to permit companies like Cloudflare greater freedom to ensure that the general population in Iran can have access to the Internet to support their cause.

Although issues like war, oppression, and misinformation are as old as humanity itself, the Internet is novel in its ability to bring together marginalized people who previously were unable to find and engage with each other based on distance, repression, or resources. To make sure the Internet fulfills that part of its promise, Project Galileo celebrated its 8th anniversary this year, and continues to support groups that unite underprivileged girls in India, the LGBTQIA+ community in the Nile River Valley, refugees needing health care services in a private environment. In total, through Project Galileo we provide Cloudflare’s services for free to more than 2,100 organizations in over 100 countries. That’s some of the work I’m the most proud of.

Over the course of this Impact Week, we will tell other stories about the way that the Internet, and Cloudflare specifically, provide an optimistic opportunity to improve our world. And that includes the entire world, especially as the Internet is poised to further close the gaps that have existed in Internet services to the developing world since its founding.

We will describe the way Cloudflare is focused on our own impact through emissions and the lessons we are applying to our products and operations to make sure that we are being responsible stewards of the Earth’s resources. We will review the ways that we are working to ensure that the necessary resources needed to benefit from the Internet aren’t limited to large companies with big budgets and the resources to buy the best tools.

From individuals and small businesses, to nonprofits and other community organizations, we want to make sure that the costs of cybersecurity and reliability don’t exclude those poised to benefit the most from the Internet. Specifically this year, we’re focused on making sure that sensitive groups — including local governments and critical infrastructure — are benefiting from new Zero Trust tools that are increasingly necessary for all organizations.

At the end of the week, we’ll release our annual Impact Report that provides a comprehensive review of our approach to these issues, especially when it comes to sustainability and ensuring that the Internet remains a widely-available and principled place.

We take pride in the principles that lie at the core of what we do as a company. Although many of us wake up every day scanning the Internet for the latest cyberattacks that we have to address or the latest congestion on the Internet to relieve, we are energized by the Internet’s ongoing promise to make life better for billions of people. This Impact Week we get to wake up and focus on those stories and share with you why all of us are here. We hope you are as excited as we are.

Adjusting pricing, introducing annual plans, and accelerating innovation

2022-11-30 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/adjusting-pricing-introducing-annual-plans-and-accelerating-innovation/

Adjusting pricing, introducing annual plans, and accelerating innovation

This post is also available in 繁體中文, 简体中文, 日本語, 한국어, Deutsch, Français, Pусский, Español, Português.

Cloudflare is raising prices for the first time in the last 12 years. Beginning January 15, 2023, new sign ups will be charged \$25 per month for our Pro Plan (up from \$20 per month) and \$250 per month for our Business Plan (up from \$200 per month). Any paying customers who sign up before January 15, 2023, including any currently paying customers who signed up at any point over the last 12 years, will be grandfathered at the old monthly price until May 14, 2023.

We are also introducing an option to pay annually, rather than monthly, that we hope most customers will choose to switch to. Annual plans are available today and discounted from the new monthly rate to \$240 per year for the Pro Plan (the equivalent of \$20 per month, saving \$60 per year) and \$2,400 per year for the Business Plan (the equivalent of \$200 per month, saving \$600 per year). In other words, if you choose to pay annually for Cloudflare you can lock in our old monthly prices.

After not raising prices in our history, this was something we thought carefully about before deciding to do. While we have over a decade of network expansion and innovation under our belts, what may not be intuitive is that our goal is not to increase revenue from this change. We need to invest up front in building out our network, and the main reason we’re making this change is to more closely map our business with the timing of our underlying costs. Doing so will enable us to further accelerate our network expansion and pace of innovation — which all of our customers will benefit from. Since this is a big change for us, I wanted to take the time to walk through how we came to this decision.

Cloudflare’s history

Cloudflare launched on September 27, 2010. At the time we had two plans: one Free Plan that was free, and a Pro Plan that cost $20 per month. Our network at the time consisted of “four and a half” data centers: Chicago, Illinois; Ashburn, Virginia; San Jose, California; Amsterdam, Netherlands; and Tokyo, Japan. The routing to Tokyo was so flaky that we’d turn it off for half the day to not mess up routing around the rest of the world. The biggest difference for the first couple years between our Free and Pro Plans was that only the latter included HTTPS support.

In June 2012, we introduced our Business Plan for $200 per month and our Enterprise Plan which was customized for our largest customers. By then we’d not only gotten Tokyo to work reliably but added 18 more data centers around the world for a total of 23. Our Business plan added DDoS mitigation as the primary benefit, something prior to then we’d been terrified to offer.

My how you’ve grown

Fast-forward to today and a lot has changed. We’re up to presence in more than 275 cities in more than 100 countries worldwide. We included HTTPS support in our Free Plan with the launch of Universal SSL in September 2014. We included unlimited DDoS mitigation in our Free Plan with the launch of Unmetered DDoS Mitigation in September 2017. Today, we stop attacks for Free Plan customers on a daily basis that are more than 10-times as big as what was headline news back in 2013.

Our strategy has always been to roll features out, limit them at first to higher tiers of paying customers, but, over time, roll them down through our plans and eventually to even our Free Plan customers. We believe everyone should be fast, reliable, and secure online regardless of their budget. And we believe our continued success should be primarily driven by new innovation, not by milking old features for revenue.

And we’ve delivered on that promise, accelerating our roll out of new features across our platform and bundling them into our existing plans without increasing prices. What you get for our Free, Pro, and Business Plans today is orders of magnitude more valuable across every dimension — performance, reliability, and security — than those plans were when they launched.

And yet we know we are our customers’ infrastructure. You rely on us. And therefore we have been very reluctant to ever raise prices just to take price and capture more revenue.

Annual plans for even faster innovation

Early on, we only charged monthly because we were an unproven service we knew customers were taking a risk on. Today, that’s no longer the case. The majority of our customers have been using us for years and, from our conversations with them, plan to continue using us for the foreseeable future. In fact, one of the top requests we receive is from customers who want to pay once per year rather than getting billed every month.

While I’m proud of our pace of innovation, one of the challenges we have is managing the cash flow to fund those investments as quickly as we’d like. We invest up front in building out our network or developing a new feature, but then only get paid monthly by our customers. That, inherently, is a governor on our pace of innovation. We can invest even faster — hire more engineers, deploy more servers — if those customers who know they’re going to use us for the next year pay for us up front. We have no shortage of things we know customers want us to build, so by collecting revenue earlier we know we can unlock even faster innovation.

In other words, we are making this change hoping most of you won’t pay us anything more than you did before. Instead, our hope is that most of you will adopt our annual plans — you’ll get to lock in the existing pricing, and you’ll help us further accelerate our network growth and pace of innovation.

Finally, I wanted to mention that something isn’t changing: our Free Plan. It will still be free. It will still have all the features it has today. And we’re still committed to, over time, rolling many more features that are only available in paid plans today down to the Free Plan over time. Our mission is to help build a better Internet. We want to win by being the most innovative company in the world. And that means making our services available to as many people as possible, even those who can’t afford to pay us right now.

But, for those of you who can pay: thank you. You’ve funded our innovation to date. And I hope you’ll opt to switch to our annual billing, so we can further accelerate our network expansion and pace of innovation.

Cloudflare’s 2022 Annual Founders’ Letter

2022-09-25 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/cloudflares-annual-founders-letter-2022/

Cloudflare’s 2022 Annual Founders’ Letter

Cloudflare launched on September 27, 2010. This week we’ll celebrate our 12th birthday. As has become our tradition, we’ll be announcing a series of products that we think of as our gifts back to the Internet. In previous years, these have included products and initiatives like Universal SSL, Cloudflare Workers, our Zero Markup Registrar, the Bandwidth Alliance, and R2 — our zero egress fee object store — which went GA last week.

We’re really excited for what we’ll be announcing this year and hope to surprise and delight all of you over the course of the week with the products and features we believe live up to our mission of helping build a better Internet.

Founders’ letter

While this will be our 12th Birthday Week of product announcements, for the last two years, as the cofounders of the company, we’ve also taken this time as an opportunity to write a letter publicly reflecting on the previous year and what’s on our minds as we go into the year ahead.

Since our last birthday, it’s been a tale of two halves of a very different year. At the end of 2021 and into the first two months of 2022, COVID infection rates were falling globally, effective vaccines were getting rolled out, and the world seemed to be returning to a sense of pre-pandemic normalcy.

Internally, we were starting to meet again in person with colleagues and customers. We’d weathered an unprecedented increase in traffic across our network caused by the pandemic and, with a few bumps along the way, used the challenges we’d faced through that time to rebuild our architecture to be more stable and reliable for the long term. We both felt optimistic for the future.

Russia’s invasion of Ukraine

Then, on February 24, Russia invaded Ukraine. While we were fortunate to not have team members working from Russia, Ukraine, or Belarus, we have many employees with families in the region and six offices within a train ride of the front lines. We watched in real time as Internet traffic patterns across Ukraine shifted, a disturbing reflection of what was happening on the ground as cities were bombed and families fled.

At the same time, Russia ratcheted up their efforts to censor their country’s Internet of all non-Russia media. While we had seen some Internet restrictions in Russia over the years, historically Russian citizens were generally able to freely access nearly any resources online. The dramatically increased censorship marked an extreme change in policy and the first time a country of any scale had tried to go from a generally open Internet to one that was fully censored.

Glimmers of hope

But, even as the war continues to rage, there is reason for optimism. In spite of a significant increase in censorship inside Russia, physical links to the rest of the world being cut in Ukraine, cyber attacks targeting Ukrainian infrastructure, and Russian forces actively rerouting BGP in invaded regions, by and large the Internet has continued to flow. As John Gilmore once famously said: “The Internet sees censorship as damage and routes around it.”

The private sector and governments around the world came together to help support Ukraine and render Russian cyberattacks largely moot. Our team provided our services for free to government, financial services, media, and civil society organizations that came under cyber attack, ensuring they stayed online. As the physical Internet links were severed in the country, our network teams worked to route traffic through every possible path to ensure not only could news from outside Ukraine get in but, equally importantly, pictures and news of the war could get out.

Those pictures and news of what is happening inside Ukraine continue to galvanize support. The Ukrainian government continues to function in spite of withering cyber attacks. Voices inside Russia pushing back against the regime are increasingly being heard. And ordinary Russian citizens have increasingly turned to services like Cloudflare’s 1.1.1.1 App to see uncensored news, in record numbers.

Our efforts to keep the Internet on in Russia led the Putin regime to officially sanction one of us (Matthew) — a sign we took that we were making a positive impact. Today we estimate approximately 5% of all households in the country are continuing to access the uncensored Internet using our 1.1.1.1 App, and that number continues to grow.

The Internet’s current battleground

2022 was not the first year in which the Internet became a battleground, but to us, it does feel like a turning point. In the last twelve months, we’ve seen more countries shut down Internet access than in any previous year. Sometimes this is just a misguided and ineffectual effort to keep students from cheating on national exams. Unfortunately, increasingly, it’s about repressive regimes attempting to assert control.

As we write this, the Iranian government is attempting to silence protests in the country through broad Internet censorship. While some may suggest this is business as usual, in fact it is not. The Internet and the broad set of news and opinions it brings have generally been available in places like Iran and Russia, and we shouldn’t accept that full censorship in them is the de facto status quo.

And these efforts to reign in the Internet are unfortunately not limited to Iran and Russia. Even in the liberal, democratic corners of Western Europe, incidents in which court ordered blocking at the infrastructure layer resulting in massive overblocking spiked dramatically over the last year. Those cases will set a dangerous precedent that a single court in a single country can block access to wide swaths of the Internet.

While it may seem ok to Austrians for an Austrian court to enforce Austrian values for an issue within Austria, if any country’s courts can block content at the core Internet infrastructure level even when it results in the blocking of unrelated sites then it will have a global impact. And, inherently, it will open the door for Afghanistan, Albania, Algeria, Andorra, Angola, Antigua, Argentina, Armenia, Australia, and Azerbaijan to do the same. And that’s just the countries that start with the letter A. If these precedents are upheld then the Internet risks falling to the lowest common denominator of what’s globally acceptable.

An old threat to permissionless innovation

The magic of the early Internet was that it was permissionless. Cloudflare was founded to counter an old and very different threat to that magic than we face today. Early in Cloudflare’s history, we used to get asked who we were competing against. We have never thought the answer was Akamai or EdgeCast. While, from a business perspective, we always thought of our business as replacing the vast catalog of Cisco’s hardware boxes with scalable services, that transition seemed inevitable. Instead, the existential competitor we faced was a threat to the permissionless Internet itself: Facebook.

If you find your eyebrow raised as you read that, know you’re not alone. It was the universal reaction we’d get whenever we said that back in 2010, and it remains the universal reaction we get when we say it today. But it has always rung true. In 2010, when Cloudflare launched, it was getting so difficult to be online — between spam, hackers, DDoS, reliability, and performance issues — that many people, organizations, and businesses gave up on the web and sought a safe space in Facebook’s walled garden.

If the challenges of being online weren’t solved in some other way, there was real risk that Facebook would, effectively, become the Internet. The magic of the Internet was that anyone with an idea could put it online and, if it resonated, thrive without having to pass through a gatekeeper. It seemed wrong to us that if those trends continued you’d have to effectively get Facebook’s permission just be online. Preserving the permissionless Internet was a big part of what motivated us to start Cloudflare.

So we set out to help solve the problems of cyberattacks, outages, and other performance challenges making sure that the Internet we believed in could continue to thrive. We built a global network able to mitigate the largest DDoS attacks easily, and to make anything connected to the Internet faster, more secure, and more reliable. We created tools to make it easy for developers to build and maintain new platforms, with the ability to deploy serverless code in an instant across the globe. We developed new ways for our customers to protect their internal systems from attack with Zero Trust services. And we made it all as widely available as possible, constantly striving to provide accessible tools not only to the Fortune 1000 but also to the small businesses, nonprofits, and developers with ideas about how to build something new, creative, and good for the world.

It’s not dissimilar to the story of another disruptive tech company that began a few years before we did. Shopify has been a long time Cloudflare customer using a number of our services, including our Workers developer platform. Their unofficial rallying cry of “arming the rebels” has always resonated with us.

In many ways, Shopify is to Amazon.com as Cloudflare is to Facebook. Both of the former providing the key infrastructure you need to innovate and then getting out of your way, both of the latter building a walled garden from which they can ultimately extract maximum rents.

A New Hope

Shopify framing their customers as the rebels taking on the Empire of Amazon is, of course, a reference to Star Wars and so it may not be surprising that we often talk internally about the Star Wars movies as a metaphor for the history of the Internet: past, present, and maybe future.

The first movie, Episode IV, was titled “A New Hope.” The plot of that movie feels a lot like how the world experienced the Internet for the 40 years prior to 2016. There was this magical thing called the Force, and it was controlled by these incredible people called Jedi. Except instead of the Force it was the Internet and instead of Jedi it was programmers and network engineers.

It’s easy to forget that it’s the stuff of not-too-long-ago science fiction that you could have a device in your pocket that could access the sum of all human knowledge. And yet, there are now more smartphones in active use than humans on Earth. Neither of us feel all that old, yet we both grew up in a time when if you had an opinion and wanted to get it out to a broad audience you had to write it up, send it in as a letter to the editor, and hope that it would get published.

Today in the world of Twitter and TikTok that is almost unimaginably quaint. The Internet blew that all up, just as Luke blew up the Death Star, and it’s hard to overstate how much that disrupted every traditional source of power and control.

The Empire Strikes Back

But after Episode IV came Episode V: “The Empire Strikes Back.” And make no mistake, the traditional centers of control are working hard to find ways to control the Internet. While we think the shift came somewhere around 2016, it feels like in 2022 the Empire has discovered the rebel base on Hoth and the AT-ATs are closing in.

Episode V is a pretty dark movie. Spoiler alert for the small percentage of you who may not have seen it, but the hero realizes his mortal enemy is his father, loses his hand, his rogue friend is encased in carbonite, and the girl he likes sold into slug slavery shortly after she declares her love for not him but the about-to-be-carbonite-encased friend. But it’s also the best movie because the stakes are so high.

The stakes are high for the Internet too, and we believe it’s important for us to engage on the hard technology and policy issues. The next several years will be challenging as we rebuild the legacy protocols of the Internet to be more private and secure by design, so they can accommodate what the Internet has become, and wrestle with hard policy issues around respecting local laws and norms on a network that is inherently global. The team at Cloudflare comes to work every day appreciating the challenges and importance of what we need to help do to live up to our mission.

Helping build a better Internet

Our mission is to help build a better Internet, and we are proud that more than 20% of the web and 30% of the Fortune 1,000 relies on Cloudflare to be fast, reliable, secure, efficient, and private for whatever they are doing online. Throughout the year we have Innovation Weeks usually dedicated to new products to sell to our customers. But, during our Birthday Week, we give back with products and initiatives that aren’t designed to generate revenue, but instead we provide them because they improve the fundamentals of how the Internet works.

And so this year we’ll be launching new services and partnerships to make the best security practices more affordable and bring them more easily to an increasingly mobile world. We’re helping developers access more resources they need to deliver the next generation of applications. And we’re launching privacy-preserving alternatives to widely used services because we believe a better Internet is a more private Internet.

We’re not ready to declare that it’s time for the Ewoks to start dancing, but we are proud of our continued innovation and the thoughtfulness of our team as we navigate these challenging times. Although the global economy continues to provide uncertain headwinds as we head into the new year, we are confident we have the plan and the team that will make us successful.

Thank you to our team, our customers, and our investors. Happy 12th birthday to Cloudflare. And, as always: we’re just getting started.

Blocking Kiwifarms

2022-09-04 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/kiwifarms-blocked/

Blocking Kiwifarms

We have blocked Kiwifarms. Visitors to any of the Kiwifarms sites that use any of Cloudflare’s services will see a Cloudflare block page and a link to this post. Kiwifarms may move their sites to other providers and, in doing so, come back online, but we have taken steps to block their content from being accessed through our infrastructure.

This is an extraordinary decision for us to make and, given Cloudflare’s role as an Internet infrastructure provider, a dangerous one that we are not comfortable with. However, the rhetoric on the Kiwifarms site and specific, targeted threats have escalated over the last 48 hours to the point that we believe there is an unprecedented emergency and immediate threat to human life unlike we have previously seen from Kiwifarms or any other customer before.

Escalating threats

Kiwifarms has frequently been host to revolting content. Revolting content alone does not create an emergency situation that necessitates the action we are taking today. Beginning approximately two weeks ago, a pressure campaign started with the goal to deplatform Kiwifarms. That pressure campaign targeted Cloudflare as well as other providers utilized by the site.

Cloudflare provides security services to Kiwifarms, protecting them from DDoS and other cyberattacks. We have never been their hosting provider. As we outlined last Wednesday, we do not believe that terminating security services is appropriate, even to revolting content. In a law-respecting world, the answer to even illegal content is not to use other illegal means like DDoS attacks to silence it.

We are also not taking this action directly because of the pressure campaign. While we have empathy for its organizers, we are committed as a security provider to protecting our customers even when they run deeply afoul of popular opinion or even our own morals. The policy we articulated last Wednesday remains our policy. We continue to believe that the best way to relegate cyberattacks to the dustbin of history is to give everyone the tools to prevent them.

However, as the pressure campaign escalated, so did the rhetoric on the Kiwifarms site. Feeling attacked, users of the site became even more aggressive. Over the last two weeks, we have proactively reached out to law enforcement in multiple jurisdictions highlighting what we believe are potential criminal acts and imminent threats to human life that were posted to the site.

Legal process

While law enforcement in these areas are working to investigate what we and others reported, unfortunately the process is moving more slowly than the escalating risk. While we believe that in every other situation we have faced — including the Daily Stormer and 8chan — it would have been appropriate as an infrastructure provider for us to wait for legal process, in this case the imminent and emergency threat to human life which continues to escalate causes us to take this action.

Hard cases make bad law. This is a hard case and we would caution anyone from seeing it as setting precedent. The policies we articulated last Wednesday remain our policies. For an infrastructure provider like Cloudflare, legal process is still the correct way to deal with revolting and potentially illegal content online.

But we need a mechanism when there is an emergency threat to human life for infrastructure providers to work expediently with legal authorities in order to ensure the decisions we make are grounded in due process. Unfortunately, that mechanism does not exist and so we are making this uncomfortable emergency decision alone.

Not the end

Finally, we are aware and concerned that our action may only fan the flames of this emergency. Kiwifarms itself will most likely find other infrastructure that allows them to come back online, as the Daily Stormer and 8chan did themselves after we terminated them. And, even if they don’t, the individuals that used the site to increasingly terrorize will feel even more isolated and attacked and may lash out further. There is real risk that by taking this action today we may have further heightened the emergency.

We will continue to work proactively with law enforcement to help with their investigations into the site and the individuals who have posted what may be illegal content to it. And we recognize that while our blocking Kiwifarms temporarily addresses the situation, it by no means solves the underlying problem. That solution will require much more work across society. We are hopeful that our action today will help provoke conversations toward addressing the larger problem. And we stand ready to participate in that conversation.

Cloudflare’s abuse policies & approach

2022-08-31 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/cloudflares-abuse-policies-and-approach/

Cloudflare's abuse policies & approach

Cloudflare launched nearly twelve years ago. We’ve grown to operate a network that spans more than 275 cities in over 100 countries. We have millions of customers: from small businesses and individual developers to approximately 30 percent of the Fortune 500. Today, more than 20 percent of the web relies directly on Cloudflare’s services.

Over the time since we launched, our set of services has become much more complicated. With that complexity we have developed policies around how we handle abuse of different Cloudflare features. Just as a broad platform like Google has different abuse policies for search, Gmail, YouTube, and Blogger, Cloudflare has developed different abuse policies as we have introduced new products.

We published our updated approach to abuse last year at:

https://www.cloudflare.com/trust-hub/abuse-approach/

However, as questions have arisen, we thought it made sense to describe those policies in more detail here.

The policies we built reflect ideas and recommendations from human rights experts, activists, academics, and regulators. Our guiding principles require abuse policies to be specific to the service being used. This is to ensure that any actions we take both reflect the ability to address the harm and minimize unintended consequences. We believe that someone with an abuse complaint must have access to an abuse process to reach those who can most effectively and narrowly address their complaint — anonymously if necessary. And, critically, we strive always to be transparent about both our policies and the actions we take.

Cloudflare’s products

Cloudflare provides a broad range of products that fall generally into three buckets: hosting products (e.g., Cloudflare Pages, Cloudflare Stream, Workers KV, Custom Error Pages), security services (e.g., DDoS Mitigation, Web Application Firewall, Cloudflare Access, Rate Limiting), and core Internet technology services (e.g., Authoritative DNS, Recursive DNS/1.1.1.1, WARP). For a complete list of our products and how they map to these categories, you can see our Abuse Hub.

As described below, our policies take a different approach on a product-by-product basis in each of these categories.

Hosting products

Hosting products are those products where Cloudflare is the ultimate host of the content. This is different from products where we are merely providing security or temporary caching services and the content is hosted elsewhere. Although many people confuse our security products with hosting services, we have distinctly different policies for each. Because the vast majority of Cloudflare customers do not yet use our hosting products, abuse complaints and actions involving these products are currently relatively rare.

Our decision to disable access to content in hosting products fundamentally results in that content being taken offline, at least until it is republished elsewhere. Hosting products are subject to our Acceptable Hosting Policy. Under that policy, for these products, we may remove or disable access to content that we believe:

Contains, displays, distributes, or encourages the creation of child sexual abuse material, or otherwise exploits or promotes the exploitation of minors.
Infringes on intellectual property rights.
Has been determined by appropriate legal process to be defamatory or libelous.
Engages in the unlawful distribution of controlled substances.
Facilitates human trafficking or prostitution in violation of the law.
Contains, installs, or disseminates any active malware, or uses our platform for exploit delivery (such as part of a command and control system).
Is otherwise illegal, harmful, or violates the rights of others, including content that discloses sensitive personal information, incites or exploits violence against people or animals, or seeks to defraud the public.

We maintain discretion in how our Acceptable Hosting Policy is enforced, and generally seek to apply content restrictions as narrowly as possible. For instance, if a shopping cart platform with millions of customers uses Cloudflare Workers KV and one of their customers violates our Acceptable Hosting Policy, we will not automatically terminate the use of Cloudflare Workers KV for the entire platform.

Our guiding principle is that organizations closest to content are best at determining when the content is abusive. It also recognizes that overbroad takedowns can have significant unintended impact on access to content online.

Security services

The overwhelming majority of Cloudflare’s millions of customers use only our security services. Cloudflare made a decision early in our history that we wanted to make security tools as widely available as possible. This meant that we provided many tools for free, or at minimal cost, to best limit the impact and effectiveness of a wide range of cyberattacks. Most of our customers pay us nothing.

Giving everyone the ability to sign up for our services online also reflects our view that cyberattacks not only should not be used for silencing vulnerable groups, but are not the appropriate mechanism for addressing problematic content online. We believe cyberattacks, in any form, should be relegated to the dustbin of history.

The decision to provide security tools so widely has meant that we’ve had to think carefully about when, or if, we ever terminate access to those services. We recognized that we needed to think through what the effect of a termination would be, and whether there was any way to set standards that could be applied in a fair, transparent and non-discriminatory way, consistent with human rights principles.

This is true not just for the content where a complaint may be filed but also for the precedent the takedown sets. Our conclusion — informed by all of the many conversations we have had and the thoughtful discussion in the broader community — is that voluntarily terminating access to services that protect against cyberattack is not the correct approach.

Avoiding an abuse of power

Some argue that we should terminate these services to content we find reprehensible so that others can launch attacks to knock it offline. That is the equivalent argument in the physical world that the fire department shouldn’t respond to fires in the homes of people who do not possess sufficient moral character. Both in the physical world and online, that is a dangerous precedent, and one that is over the long term most likely to disproportionately harm vulnerable and marginalized communities.

Today, more than 20 percent of the web uses Cloudflare’s security services. When considering our policies we need to be mindful of the impact we have and precedent we set for the Internet as a whole. Terminating security services for content that our team personally feels is disgusting and immoral would be the popular choice. But, in the long term, such choices make it more difficult to protect content that supports oppressed and marginalized voices against attacks.

Refining our policy based on what we’ve learned

This isn’t hypothetical. Thousands of times per day we receive calls that we terminate security services based on content that someone reports as offensive. Most of these don’t make news. Most of the time these decisions don’t conflict with our moral views. Yet two times in the past we decided to terminate content from our security services because we found it reprehensible. In 2017, we terminated the neo-Nazi troll site The Daily Stormer. And in 2019, we terminated the conspiracy theory forum 8chan.

In a deeply troubling response, after both terminations we saw a dramatic increase in authoritarian regimes attempting to have us terminate security services for human rights organizations — often citing the language from our own justification back to us.

Since those decisions, we have had significant discussions with policy makers worldwide. From those discussions we concluded that the power to terminate security services for the sites was not a power Cloudflare should hold. Not because the content of those sites wasn’t abhorrent — it was — but because security services most closely resemble Internet utilities.

Just as the telephone company doesn’t terminate your line if you say awful, racist, bigoted things, we have concluded in consultation with politicians, policy makers, and experts that turning off security services because we think what you publish is despicable is the wrong policy. To be clear, just because we did it in a limited set of cases before doesn’t mean we were right when we did. Or that we will ever do it again.

But that doesn’t mean that Cloudflare can’t play an important role in protecting those targeted by others on the Internet. We have long supported human rights groups, journalists, and other uniquely vulnerable entities online through Project Galileo. Project Galileo offers free cybersecurity services to nonprofits and advocacy groups that help strengthen our communities.

Through the Athenian Project, we also play a role in protecting election systems throughout the United States and abroad. Elections are one of the areas where the systems that administer them need to be fundamentally trustworthy and neutral. Making choices on what content is deserving or not of security services, especially in any way that could in any way be interpreted as political, would undermine our ability to provide trustworthy protection of election infrastructure.

Regulatory realities

Our policies also respond to regulatory realities. Internet content regulation laws passed over the last five years around the world have largely drawn a line between services that host content and those that provide security and conduit services. Even when these regulations impose obligations on platforms or hosts to moderate content, they exempt security and conduit services from playing the role of moderator without legal process. This is sensible regulation borne of a thorough regulatory process.

Our policies follow this well-considered regulatory guidance. We prevent security services from being used by sanctioned organizations and individuals. We also terminate security services for content which is illegal in the United States — where Cloudflare is headquartered. This includes Child Sexual Abuse Material (CSAM) as well as content subject to Fight Online Sex Trafficking Act (FOSTA). But, otherwise, we believe that cyberattacks are something that everyone should be free of. Even if we fundamentally disagree with the content.

In respect of the rule of law and due process, we follow legal process controlling security services. We will restrict content in geographies where we have received legal orders to do so. For instance, if a court in a country prohibits access to certain content, then, following that court’s order, we generally will restrict access to that content in that country. That, in many cases, will limit the ability for the content to be accessed in the country. However, we recognize that just because content is illegal in one jurisdiction does not make it illegal in another, so we narrowly tailor these restrictions to align with the jurisdiction of the court or legal authority.

While we follow legal process, we also believe that transparency is critically important. To that end, wherever these content restrictions are imposed, we attempt to link to the particular legal order that required the content be restricted. This transparency is necessary for people to participate in the legal and legislative process. We find it deeply troubling when ISPs comply with court orders by invisibly blackholing content — not giving those who try to access it any idea of what legal regime prohibits it. Speech can be curtailed by law, but proper application of the Rule of Law requires whoever curtails it to be transparent about why they have.

Core Internet technology services

While we will generally follow legal orders to restrict security and conduit services, we have a higher bar for core Internet technology services like Authoritative DNS, Recursive DNS/1.1.1.1, and WARP. The challenge with these services is that restrictions on them are global in nature. You cannot easily restrict them just in one jurisdiction so the most restrictive law ends up applying globally.

We have generally challenged or appealed legal orders that attempt to restrict access to these core Internet technology services, even when a ruling only applies to our free customers. In doing so, we attempt to suggest to regulators or courts more tailored ways to restrict the content they may be concerned about.

Unfortunately, these cases are becoming more common where largely copyright holders are attempting to get a ruling in one jurisdiction and have it apply worldwide to terminate core Internet technology services and effectively wipe content offline. Again, we believe this is a dangerous precedent to set, placing the control of what content is allowed online in the hands of whatever jurisdiction is willing to be the most restrictive.

So far, we’ve largely been successful in making arguments that this is not the right way to regulate the Internet and getting these cases overturned. Holding this line we believe is fundamental for the healthy operation of the global Internet. But each showing of discretion across our security or core Internet technology services weakens our argument in these important cases.

Paying versus free

Cloudflare provides both free and paid services across all the categories above. Again, the majority of our customers use our free services and pay us nothing.

Although most of the concerns we see in our abuse process relate to our free customers, we do not have different moderation policies based on whether a customer is free versus paid. We do, however, believe that in cases where our values are diametrically opposed to a paying customer that we should take further steps to not only not profit from the customer, but to use any proceeds to further our companies’ values and oppose theirs.

For instance, when a site that opposed LGBTQ+ rights signed up for a paid version of DDoS mitigation service we worked with our Proudflare employee resource group to identify an organization that supported LGBTQ+ rights and donate 100 percent of the fees for our services to them. We don’t and won’t talk about these efforts publicly because we don’t do them for marketing purposes; we do them because they are aligned with what we believe is morally correct.

Rule of Law

While we believe we have an obligation to restrict the content that we host ourselves, we do not believe we have the political legitimacy to determine generally what is and is not online by restricting security or core Internet services. If that content is harmful, the right place to restrict it is legislatively.

We also believe that an Internet where cyberattacks are used to silence what’s online is a broken Internet, no matter how much we may have empathy for the ends. As such, we will look to legal process, not popular opinion, to guide our decisions about when to terminate our security services or our core Internet technology services.

In spite what some may claim, we are not free speech absolutists. We do, however, believe in the Rule of Law. Different countries and jurisdictions around the world will determine what content is and is not allowed based on their own norms and laws. In assessing our obligations, we look to whether those laws are limited to the jurisdiction and consistent with our obligations to respect human rights under the United Nations Guiding Principles on Business and Human Rights.

There remain many injustices in the world, and unfortunately much content online that we find reprehensible. We can solve some of these injustices, but we cannot solve them all. But, in the process of working to improve the security and functioning of the Internet, we need to make sure we don’t cause it long-term harm.

We will continue to have conversations about these challenges, and how best to approach securing the global Internet from cyberattack. We will also continue to cooperate with legitimate law enforcement to help investigate crimes, to donate funds and services to support equality, human rights, and other causes we believe in, and to participate in policy making around the world to help preserve the free and open Internet.

Políticas y enfoque de Cloudflare contra el abuso

2022-08-31 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/cloudflares-abuse-policies-and-approach-es-es/

Políticas y enfoque de Cloudflare contra el abuso

Cloudflare comenzó su andadura hace casi doce años. Hemos crecido hasta operar una red que abarca más de 275 ciudades en más de 100 países. Tenemos millones de clientes, desde pequeñas empresas y desarrolladores particulares hasta aproximadamente el 30 % de las empresas incluidas en la lista Fortune 500. Hoy día, más del 20 % de los sitios web dependen directamente de los servicios de Cloudflare.

Desde nuestros inicios, nuestro conjunto de servicios han ganado en complejidad. Con ello en mente, hemos desarrollado políticas sobre cómo hacemos frente al abuso de las diferentes funciones de Cloudflare. Al igual que una plataforma amplia como Google tiene diferentes políticas de abuso para las funciones de búsqueda, Gmail, YouTube y Blogger, Cloudflare ha desarrollado diferentes políticas en materia de abuso conforme hemos ido incorporando nuevos productos.

Publicamos nuestro enfoque actualizado en materia de abuso el año pasado en:

https://www.cloudflare.com/trust-hub/abuse-approach/

Sin embargo, como han surgido algunas dudas, hemos pensado que tenía sentido describir esas políticas con más detalle aquí.

Las políticas que hemos elaborado reflejan ideas y recomendaciones de expertos en derechos humanos, activistas, académicos y organismos reguladores. Nuestros principios rectores exigen que las políticas en materia de abuso sean específicas para el servicio que se utiliza. De esta forma nos aseguramos que cualquier medida que adoptemos refleja la capacidad de abordar los efectos causados y minimizar las consecuencias no deseadas. Creemos que alguien que desee notificar un abuso debe tener acceso a un proceso que le permita contactar con quienes puedan dar una respuesta más específica y eficaz a su denuncia, de forma anónima si es necesario. Y, lo que es más importante, nos esforzamos por ser siempre transparentes tanto en nuestras políticas como en las medidas que adoptamos.

Nuestros productos

Cloudflare ofrece una amplia gama de productos que, en general, se dividen en tres categorías: productos de alojamiento (p. ej. Cloudflare Pages, Cloudflare Stream, Workers KV, páginas de error personalizadas), servicios de seguridad (p. ej. mitigación de DDoS, firewall de aplicaciones web, Cloudflare Access, limitación de velocidad) y servicios de tecnología de Internet (p. ej. DNS autoritativo, DNS recursivo / 1.1.1.1, WARP). Para obtener una lista completa de nuestros productos y su correspondencia con estas categorías, puedes consultar nuestro Centro de abuso.

Como se describe a continuación, nuestras políticas adoptan un enfoque diferente producto por producto en cada una de estas categorías.

Productos de alojamiento

Los productos de alojamiento son aquellos para los que Cloudflare es la plataforma de alojamiento definitiva del contenido. Se diferencian de los productos para los que simplemente ofrecemos servicios de seguridad o almacenamiento temporal en la caché y el contenido se aloja en otro lugar. Si bien mucha gente confunde nuestros productos de seguridad con los servicios de alojamiento, tenemos políticas claramente diferentes para cada uno de ellos. Debido a que la gran mayoría de los clientes de Cloudflare aún no utilizan nuestros productos de alojamiento, las denuncias y acciones de abuso relacionadas con estos productos son relativamente infrecuentes.

Nuestra decisión de deshabilitar el acceso al contenido de los productos de alojamiento impide el acceso de ese contenido en línea, al menos hasta que se vuelva a publicar en otro lugar. Los productos de alojamiento están sujetos a nuestra política de alojamiento de uso aceptable, en virtud de la cual, podemos eliminar o inhabilitar el acceso al contenido para estos productos si consideramos que:

Contiene, muestra, distribuye o fomenta la creación de material de abuso sexual infantil, o explota o promueve de cualquier otro modo la explotación de menores.
Infringe los derechos de propiedad intelectual.
Se ha determinado mediante un procedimiento legal apropiado que es difamatorio o injurioso.
Contribuye a la distribución ilegal de sustancias controladas.
Facilita el tráfico de personas o la prostitución infringiendo la ley.
Contiene, instala o difunde cualquier tipo de malware activo, o utiliza nuestra plataforma para la difusión de vulnerabilidades (como parte de un sistema de mando y control).
Es ilegal, peligroso o vulnera los derechos de otros, incluido el contenido que revela información personal confidencial, incita o explota la violencia contra personas o animales, o intenta estafar al público.

Mantenemos la discreción en cuanto a la aplicación de nuestra política de alojamiento de uso aceptable y, por lo general, tratamos de aplicar las restricciones de contenido de la forma más estricta posible. Por ejemplo, si una plataforma de carritos de la compra con millones de clientes utiliza Cloudflare Workers KV y uno de sus clientes infringe nuestra política de alojamiento de uso aceptable, no cancelaremos automáticamente el uso de Cloudflare Workers KV para toda la plataforma.

Nuestro principio rector es que las organizaciones más cercanas al contenido son las que mejor pueden determinar cuándo es inapropiado. También reconoce que la eliminación excesiva de contenido puede tener un efecto indeseado importante sobre el acceso al contenido en línea.

Seguridad

La inmensa mayoría de los millones de clientes de Cloudflare utilizan únicamente nuestros servicios de seguridad. Cloudflare tenía claro desde el principio el deseo de que todas las herramientas de seguridad fueran lo más accesibles posible, de ahí que ofreciéramos muchas herramientas de forma gratuita, o a un coste mínimo, para limitar de la mejor manera posible el impacto y la eficacia de una amplia gama de ciberataques. La mayoría de nuestros clientes no nos pagan nada.

Ofrecer a todo el mundo la posibilidad de contratar nuestros servicios en línea también refleja nuestra opinión de que los ciberataques no solo no deben ser un medio para silenciar a los grupos vulnerables, sino que no son el mecanismo adecuado para abordar los contenidos inapropiados en línea. Creemos que los ciberataques, en cualquiera de sus formas, deben quedar relegados al cajón del olvido.

La decisión de ofrecer herramientas de seguridad de forma tan amplia nos ha obligado a recapacitar sobré cuándo debemos interrumpir el acceso a estos servicios, o si lo haremos. Reconocimos que teníamos que pensar en cuál sería la repercusión de una interrupción, y si había alguna manera de establecer normas que se pudieran aplicar de manera justa, transparente y no discriminatoria, en consonancia con los principios de los derechos humanos.

Y ello no solo en razón del contenido objeto de un posible denuncia, sino también del precedente que podría sentar una interrupción. Nuestra conclusión, precedida por las conversaciones que hemos mantenido y el debate reflexivo en la comunidad en general, es que la interrupción voluntaria del acceso a los servicios que protegen contra los ciberataques no es el enfoque correcto.

Evitar el abuso de poder

Algunos sostienen que deberíamos interrumpir estos servicios a contenidos que consideramos censurables para que otros puedan lanzar ataques que impidan su acceso en línea. En el mundo físico, este argumento es similar a la afirmación de que los bomberos no deberían responder al incendio en la vivienda de una persona que no tenga consideración moral suficiente. Ya sea en el mundo físico o en línea, se trata de un precedente peligroso que, a largo plazo, puede perjudicar de forma desproporcionada a las comunidades vulnerables y marginadas.

Hoy día, más del 20 % de los sitios web utilizan los servicios de seguridad de Cloudflare. A la hora de considerar nuestras políticas, debemos ser conscientes del impacto que tenemos y del precedente que sentamos para Internet en su conjunto. Interrumpir los servicios de seguridad para el contenido que nuestro equipo considera reprobable e inmoral sería la opción popular. Pero, a largo plazo, estas opciones dificultan la protección de los contenidos que defienden las voces acalladas y marginadas de los ataques.

Revisamos nuestra política sobre la base de la experiencia adquirida

No es hipotético. Miles de veces al día recibimos llamadas para que demos de baja servicios de seguridad debido a contenidos que alguien denuncia como ofensivos. La mayoría no son noticia. Generalmente, estas decisiones no son incompatibles con nuestras opiniones morales. Sin embargo, en dos ocasiones en el pasado decidimos retirar contenido de nuestros servicios de seguridad por considerarlo censurables. En 2017, cerramos el sitio neonazi The Daily Stormer y, en 2019, interrumpimos el foro de teorías conspirativas 8chan.

La respuesta a ambas interrupciones fue muy preocupante, tal y como demostró el aumento asombroso que observamos en los regímenes autoritarios que intentaban que suspendiéramos los servicios de seguridad de las organizaciones de derechos humanos utilizando nuestros mismos argumentos.

Estas decisiones abrieron importantes debates con responsables políticos de todo el mundo. La conclusión fue que el poder de interrumpir los servicios de seguridad para los sitios no era un poder que Cloudflare debería tener. No porque el contenido de esos sitios no fuera reprobable, que lo era, sino porque los servicios de seguridad se asemejan más a los servicios públicos de Internet.

Al igual que una compañía telefónica no cancela tu línea si dices cosas horribles, racistas e intolerables, hemos llegado a la conclusión, tras consultar con políticos, responsables de la formulación de políticas y expertos, de que desconectar los servicios de seguridad porque pensamos que lo que publicas es despreciable es una política equivocada. Para ser claros, el hecho de que lo hayamos hecho antes en pocos casos no significa que tuviéramos razón cuando lo hicimos, ni que vayamos a volver a hacerlo.

Sin embargo, eso no significa que Cloudflare no pueda desempeñar un papel importante en la protección de aquellos que son blanco de terceros en Internet. Llevamos mucho tiempo apoyando a grupos de derechos humanos, periodistas y otras entidades especialmente vulnerables en línea a través del proyecto Galileo, que ofrece servicios gratuitos de ciberseguridad a organizaciones sin ánimo de lucro y grupos activistas que ayudan a potenciar nuestras comunidades.

A través del proyecto Athenian, también desempeñamos un papel en la protección de los sistemas electorales en Estados Unidos y en el extranjero. Las elecciones son uno de los ámbitos en los que los sistemas que las administran deben ser sumamente fiables y neutrales. Tomar decisiones sobre qué contenidos merecen o no servicios de seguridad, sobre todo en cualquier forma que pudiera interpretarse como política, socavaría nuestra capacidad de proporcionar una protección fiable de la infraestructura electoral.

Realidad normativa

Nuestras políticas también responden a realidades normativas. Las leyes de regulación de contenidos de Internet aprobadas en los últimos cinco años en todo el mundo han trazado en gran medida una línea divisoria entre los servicios que alojan contenidos y los que prestan servicios de seguridad y enrutamiento. Incluso cuando estas normativas imponen a las plataformas o a los proveedores de alojamiento la obligación de moderar los contenidos, eximen a los servicios de seguridad y enrutamiento de desempeñar el papel de moderadores sin un procedimiento judicial. Se trata de una regulación sensata, fruto de un proceso normativo exhaustivo.

Nuestras políticas obedecen esta meditada directriz normativa. Evitamos que organizaciones y personas objeto de sanciones utilicen los servicios de seguridad. También interrumpimos los servicios de seguridad para el contenido que es ilegal en los Estados Unidos, donde Cloudflare tiene su sede. Se incluye el material de abuso sexual infantil (CSAM), así como el contenido sujeto a la Ley de lucha contra la explotación sexual en línea (FOSTA). Pero, por lo demás, creemos que los ciberataques son algo que nadie debería sufrir, aunque no estamos de acuerdo con el contenido.

Por respeto al Estado de derecho y al procedimiento reglamentario, cumplimos con los procesos jurídicos que controlan los servicios de seguridad. Restringiremos los contenidos en las zonas geográficas en las que hayamos recibido una orden judicial para hacerlo. Por ejemplo, si el tribunal de un país prohíbe el acceso a ciertos contenidos, entonces, en cumplimiento de la orden de ese tribunal, generalmente restringiremos el acceso a esos contenidos en ese país. Esto, en muchos casos, limitará la capacidad de acceso al contenido en el país. Sin embargo, reconocemos que el hecho de que un contenido sea ilegal en una jurisdicción no significa que lo sea en otra, por lo que adaptamos estas restricciones a la jurisdicción del tribunal o autoridad legal.

Si bien nos adherimos a los procedimientos judiciales, también creemos que la transparencia es de vital importancia. Por ello, siempre que se imponen estas restricciones de contenido, intentamos vincular la orden judicial concreta que exigió la restricción del contenido. Esta transparencia es necesaria para que la gente participe en los procedimientos jurídicos y normativos. Nos parece muy preocupante que los proveedores de servicios de Internet cumplan con las órdenes judiciales mediante el enrutamiento con reglas de filtrado invisibles de contenidos, sin dar a quienes intentan acceder a ellos ninguna idea del régimen legal que los prohíbe. La ley puede restringir el contenido, pero la correcta aplicación del Estado de derecho requiere que quien lo restrinja sea transparente en cuanto a los motivos.

Servicios tecnológicos básicos de Internet

Si bien cumplimos, por lo general, las órdenes judiciales que exigen restringir los servicios de seguridad y enrutamiento, tenemos un listón más alto para los servicios tecnológicos de Internet como el DNS autoritativo, el DNS recursivo / 1.1.1.1, y WARP. El problema con estos servicios es que las restricciones sobre ellos son de naturaleza global. No es fácil restringirlos en una jurisdicción concreta, por lo que la ley más restrictiva se acaba aplicando a nivel global.

Por lo general, hemos impugnado o recurrido las órdenes judiciales que intentan restringir el acceso a estos servicios tecnológicos básicos de Internet, incluso cuando una sentencia solo aplica a nuestros clientes suscritos al plan gratuito. Al hacerlo, intentamos sugerir a los organismos reguladores o a los tribunales formas más personalizadas de restringir los contenidos que les preocupan.

Desgraciadamente, estos casos son cada vez más frecuentes, ya que los titulares de propiedad intelectual intentan obtener una sentencia en una jurisdicción y hacer que se aplique en todo el mundo para poner fin a los principales servicios de tecnología digital y eliminar los contenidos de forma efectiva. Una vez más, creemos que este es un precedente peligroso, que deja el control de los contenidos permitidos en línea en manos de cualquier jurisdicción que esté dispuesta a ser la más restrictiva.

Por ahora, hemos logrado defender en gran medida que esta no es la forma correcta de regular Internet y hemos conseguido que se revoquen estos casos. Estamos convencidos de que seguir esta línea es fundamental para el buen funcionamiento de la red global de Internet. Sin embargo, cada muestra de discreción en nuestros servicios de seguridad o de tecnología básica de Internet debilita nuestros argumentos en estos casos importantes.

Servicios de pago vs. gratuitos

Cloudflare ofrece servicios gratuitos y de pago en todas las categorías mencionadas. De nuevo, la mayoría de nuestros clientes utilizan nuestros servicios gratuitos y no nos pagan nada.

Aunque la mayoría de las preocupaciones que observamos en nuestro procedimiento en materia de abuso hacen referencia a los clientes suscritos a nuestro plan gratuito, no tenemos políticas de moderación diferentes en función de si un cliente paga o no. Sin embargo, creemos que en los casos en los que nuestros valores son diametralmente opuestos a los de un cliente de pago, deberíamos tomar medidas adicionales no solo para no beneficiarnos del cliente, sino para utilizar lo recaudado para promover los valores de nuestra empresa y oponernos a los suyos.

Por ejemplo, cuando un sitio que se oponía a los derechos de LGBTQ+ se inscribió a un plan de pago del servicio de mitigación de DDoS, trabajamos con nuestro grupo de recursos para empleados de Proudflare para identificar una organización que apoyara los derechos de LGBTQ+ y donarles el 100 % de las tarifas de nuestros servicios. No hablamos ni hablaremos de este trabajo públicamente porque no lo hacemos con fines publicitarios, sino porque está alineados con lo que creemos que es moralmente correcto.

Estado de derecho

Si bien creemos que tenemos la obligación de restringir los contenidos que alojamos, no creemos que tengamos legitimidad política para determinar de forma general lo que está y no en línea, restringiendo la seguridad o los servicios básicos de Internet. Si ese contenido es peligroso, se tiene que restringir por vía legislativa.

También creemos que una red de Internet en la que se utilizan ciberataques para silenciar lo que está en línea es una red inservible, por mucho que sintamos empatía por los fines. Por ello, nos basaremos en los procesos judiciales, no en la opinión popular, para guiar nuestras decisiones sobre cuándo interrumpir a nuestros servicios de seguridad o a nuestros principales servicios de tecnología de Internet.

A pesar de lo que puedan afirmar algunos, no somos absolutistas de la libertad de expresión. Sin embargo, creemos en el Estado de derecho. Diferentes países y jurisdicciones de todo el mundo determinarán qué contenidos se permiten o no en función de sus propias normativas y leyes. En la evaluación de nuestras obligaciones, nos fijamos en si esas leyes se limitan a la jurisdicción y son coherentes con nuestras obligaciones de respetar los derechos humanos según los Principios Rectores de Empresas y DD.HH de la ONU.

Sigue habiendo muchas injusticias en el mundo y, por desgracia, muchos contenidos en línea que nos parecen censurables. Podemos resolver algunas de estas injusticias, pero no todas. Pero, en el proceso de mejorar la seguridad y el funcionamiento de Internet, tenemos que asegurarnos de no causar daños a largo plazo.

Seguiremos hablando sobre estos retos y sobre la mejor manera de abordar la seguridad de Internet global frente a los ciberataques. También seguiremos cooperando con las fuerzas de seguridad legítimas para ayudar a investigar los delitos, donar fondos y servicios para promover la igualdad, los derechos humanos y otras causas en las que creemos, y participar en la elaboración de políticas en todo el mundo para ayudar a preservar una red de Internet libre y abierta.

Cloudflareの不正利用に対するポリシーとその取り組み

2022-08-31 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/cloudflares-abuse-policies-and-approach-ja-jp/

Cloudflareの不正利用に対するポリシーとその取り組み

Cloudflareは12年前に創立されました。現在では、世界100か国を超える275都市以上にネットワークを展開するまでに成長しました。中小企業や個人開発者からフォーチュン500社の約30パーセントに至るまで、何百万ものお客様を抱えています。現在では、Webの20％以上がCloudflareのサービスに直接依存しています。

サービスの立ち上げ以来、時間の経過とともに当社のサービスははるかに複雑なものになりました。このような複雑さの中で、私たちはCloudflareのさまざまな機能が不正使用された場合の扱いについてポリシーを策定しました。Googleのような広範なプラットフォームが、検索、Gmail、YouTube、Bloggerに対して異なる不正利用ポリシーを設けているように、Cloudflareも新製品の導入に伴い、それぞれに不正利用に対するポリシーを策定してきました。

昨年、当社では不正利用に対する最新のアプローチを以下のサイトで公開しました：

https://www.cloudflare.com/trust-hub/abuse-approach/

しかし、質問があがったため、ここでその方針をより詳しく説明することに意味があると考えました。

当社が構築したポリシーには、人権の専門家、活動家、学者、規制当局の考えや提言が反映されています。当社の指針では、不正利用に対するポリシーは利用対象となるサービスに特化したものであることが求められています。これは、私たちが取る行動が、被害への対処能力を反映し、意図しない結果を最小限に抑えるものであることを保証するためです。私たちは、不正利用に関する苦情を持つ人物が、その苦情に最も効果的かつ厳密に対処できる人物に（必要に応じて匿名で）連絡できるような、不正利用に対応するプロセスを利用できなければならないと考えています。また私たちは、私たちのポリシーと私たちの取る行動が常に透明性を保つように努めています。

Cloudflareの製品

ホスティング製品（Cloudflare Pages、Cloudflare Stream、Workers KV、Custom Error Pagesなど）、セキュリティサービス（DDoS軽減、Webアプリケーションファイアウォール、Cloudflare Access、レート制限など）、中核的なITサービス（権威DNS、再帰DNS/1.1.1.1、WARPなど）の3つに分類される幅広い製品群を提供しています。当社の製品の完全なリストと、それらがどのようにこれらのカテゴリにマッピングされるかについては、Abuse Hub をご覧ください。

後述するように、当社のポリシーは、これらのカテゴリー内の製品ごとに異なるアプローチをとっています。

ホスティング製品

ホスティング製品とは、Cloudflareがコンテンツの最終的なホストとなる製品です。これは、単にセキュリティや一時的なキャッシュサービスを提供し、コンテンツが別の場所でホストされるような製品とは異なります。セキュリティ製品とホスティングサービスを混同される方が多いのですが、当社はそれぞれに対して明確に異なるポリシーを持っています。Cloudflareのお客様の大多数はまだ当社のホスティング製品を使用していないため、これらの製品に関する不正利用の苦情や措置は現在のところ比較的まれです。

ホスティング製品内のコンテンツへのアクセスを無効にするという私たちの決定は、少なくとも他の場所で再公開されるまでは、基本的にそのコンテンツをオフラインにすることになります。ホスティング製品は当社のホスティング利用規定の対象となります。このポリシーのもと、これらの製品について、当社は当社が以下のように考えるコンテンツへのアクセスを削除または無効にすることができます。

児童性的虐待の素材を含む、表示する、配布する、または作成を奨励する、その他未成年者の搾取を行う、または促進している。
知的財産権を侵害している。
適切な法的手続きにより、名誉毀損または誹謗中傷行為があると判断された。
規制薬物の違法な流通に従事している。
法に違反する人身売買や売春を助長する。
アクティブなマルウェアを含む、インストールする、配布する、またはエクスプロイトを配信するために当社のプラットフォームを使用している（コマンド＆コントロールシステムの一部など）。
その他の違法、有害、または他者の権利を侵害している（機密性の高い個人情報を開示、人や動物に対する暴力を扇動または利用するもの、公衆を欺こうとするものなど）。

当社は、ホスティング利用規約をどのように実施するかについて裁量権を保持しており、一般に、コンテンツに課される制限を可能な限り狭い範囲にとどめるように努めています。例えば、数百万人のお客様が利用するショッピングカートプラットフォームでCloudflare Workers KVを使用しており、そのお客様の1人が当社の「ホスティング利用規約」に違反した場合、当社がプラットフォーム全体のCloudflare Workers KVの使用を自動的に停止することはありません。

コンテンツに最も近い組織が、コンテンツが不正であるかどうかを判断するのに最適な存在であるというのが私たちの方針です。また、行き過ぎたテイクダウンは、オンライン上のコンテンツへのアクセスに意図しない重大な影響を与える可能性があることも認識しています。

セキュリティサービス

Cloudflareの数百万人のお客様のうち、当社のセキュリティサービスのみをご利用いただいているお客様が圧倒的多数を占めています。Cloudflareは、設立当初から「セキュリティツールをできるだけ広く普及させたい」と考えていました。この考えのもと、当社はさまざまなサイバー攻撃の影響や効果を最大限抑えるために、多くのツールを無料または最小限のコストで提供してきました。ほとんどのお客さまは、当社に対する支払いはありません。

また、誰もがオンラインから当社のサービスに登録できるようにしているのは、サイバー攻撃によって立場の弱い団体の口を封じるようなことがあってはならないというだけでなく、サイバー攻撃がオンライン上の問題あるコンテンツに対処する適切なメカニズムであってもならないという当社の見解を反映したものです。私たちは、どのような形であれ、サイバー攻撃は歴史のゴミ箱に追いやられるべきだと考えています。

セキュリティツールを広く提供するということは、そのサービスへのアクセスをいつ、あるいはどのような場合に停止させるかを慎重に考えなければならないことを意味します。停止した場合にどのような影響があるのか、また、人権の原則に則り、公正、透明かつ非差別な方法で適用される基準を設定する方法はないのかについて熟慮する必要があると認識しました。

これは、苦情が寄せられる可能性のあるコンテンツだけでなく、テイクダウンがもたらす先例にも当てはまります。私たちがこれまで行ってきた多くの議論や、より広範なコミュニティでの思慮深い議論から得た私たちの結論は、サイバー攻撃から保護するサービスへのアクセスを自発的に停止させることは正しいアプローチではないということです。

権力の濫用を避ける

中には、当社が発見した避難されるべきコンテンツには攻撃を仕掛けてサービスを停止させ、オフラインにできるようにすべきだと主張する人もいます。それは、物理的な世界に置き換えた場合、十分なモラルを持たない人の家の火事には消防署が対処すべきではないという議論に相当します。物理的な世界でもオンラインでも、これは危険な前例であり、長期的には社会的弱者や疎外されたコミュニティに不当に損害を与える可能性が最も高いものです。

現在では、Webの20%以上がCloudflareのセキュリティサービスを利用しています。当社のポリシーについて検討する場合、当社がインターネット全体に与える影響と前例に留意する必要があります。私たちのチームが個人的に嫌悪感や不道徳さを感じるコンテンツのセキュリティサービスを停止することは一般的な選択でしょう。しかし、長期的に見た場合、このような選択は、抑圧され疎外された声を支援するコンテンツを攻撃から守ることをより困難にしてしまいます。

学んだことをもとにポリシーを洗練させる

これは仮定の話ではありません。誰かが不快だと報告した内容に基づいて、セキュリティサービスを停止させる趣旨の電話を、私たちは1日に何千回も受けているのです。これらのほとんどは報道されません。ほとんどの場合、こうした判断は私たちの道徳観と相反するものではありません。しかし、過去に2回、私たちが非難されるべきと判断し、セキュリティサービスからコンテンツを停止する判断を下したことがあります。2017年、私たちはネオナチのトロールサイト The Daily Stormerを停止させました。そして2019年、私たちは陰謀論フォーラム8chanを停止しました。

非常に厄介な対応として、この2つの措置の後、権威主義的な政権が人権団体のセキュリティサービスを打ち切ろうとするケースが劇的に増え、その際、当社が私たち自身の正当性を示すために出した文言を引用されることがしばしばありました。

この決定以来、私たちは世界中の政策立案者と重要な議論を行ってきました。これらの議論の結果、サイトのセキュリティサービスを停止する権限は、Cloudflareが持つべきものではないという結論に達しました。それは、これらのサイトの内容が嫌悪の対象となるようなものでなかったからではなく、セキュリティサービスがインターネット上の公益事業と最もよく似ていることが理由です。

仮にあなたが酷いことや、人種差別的、偏見的なことを言っても電話会社が回線を切断することが無いのと同様に、私たちは政治家、政策立案者、専門家と協議して、公開された内容が卑劣だと考えてもセキュリティサービスを停止するのは間違った政策であるという結論に達しました。誤解のないように言うと、以前は限られたケースでやっていたからといって、その時のやり方が正しかったとは言えません。また、二度とやらないということにもなりません。

しかし、これはCloudflareがインターネット上で他者から標的となった対象を保護する重要な役割を果たせないというわけではありません。私たちは長い間、プロジェクト・ガリレオを通じて、人権団体、ジャーナリスト、その他オンライン上で特異な弱者とされる団体を支援してきました。プロジェクト・ガリレオは、コミュニティの強化に貢献する非営利団体や支援団体に、無料のサイバーセキュリティ・サービスを提供しています。

Athenian Projectを通じて、米国内外の選挙システムを保護する役割も担っています。選挙は、それを管理するシステムが根本的に信頼でき、中立であることが必要な分野の一つです。どのようなコンテンツがセキュリティサービスに値するか否か、特にどのような形であれ政治的と解釈されかねない選択をすることは、選挙インフラの信頼できる保護を提供する我々の能力を損ねることになります。

規制の現実

また、当社のポリシーは「規制の現実」に対応した政策も行っています。過去5年間に世界中で可決されたインターネットコンテンツ規制法は、コンテンツをホストするサービスと、セキュリティとコンジットサービスを提供するサービスの間に、大きく線引きを行っています。これらの規制は、プラットフォームやホストにコンテンツをモデレートする義務を課す場合でも、セキュリティやコンジットサービスが法的手続きを経ずにモデレーターの役割を果たすことを免除しています。これは、徹底した規制のプロセスから生まれた、賢明な規制です。

当社のポリシーは、この十分に考慮された規制の指針に従っています。当社では、制裁を受けた組織や個人によるセキュリティサービスの利用を防止します。また、Cloudflareの本社がある米国で違法とされるコンテンツについてもセキュリティサービスを停止しています。これには、児童性的虐待資料（CSAM）やオンライン性的人身売買撲滅法（FOSTA）の対象となるコンテンツが含まれます。しかし、それ以外では、サイバー攻撃とは誰もが無縁でいられるべきものだと考えています。たとえ、その内容に根本的に同意できないとしても。

法の支配と適正手続きの尊重のもと、私たちは法的手続きに従ってセキュリティサービスを管理しています。私たちは、法的な命令を受けた地域では、コンテンツを制限します。例えば、ある国の裁判所が特定のコンテンツへのアクセスを禁止した場合、その裁判所の命令に従って、当社は通常、その国でのそのコンテンツへのアクセスを制限します。そのため、多くの場合、その国でアクセスできるコンテンツが制限されることになります。ただし、私たちはある法域で違法なコンテンツだからといって、他の法域でも違法とはなるわけではないことを認識しているため、これらの制限には裁判所や法的機関の管轄に合わせた狭義の制限を設けています。

私たちは法的な手続きに従う一方で、透明性を確保することが非常に重要であると考えています。そのため、コンテンツに制限が課せられる場合は、その制限を要求する特定の法的命令と結び付けられるようにしています。このような透明性は、人々が法律や立法過程に参加するために必要なものです。ISPが裁判所の命令に従う際に、目に見えない形でコンテンツをブラックホール化し、アクセスしようとする人々ににどのような法体系によって禁止されているのかを全く知らせないのは、非常に問題だと考えます。言論は法律で制限することができますが、法の支配を適切に適用するためには、言論を制限する者はその理由を明らかにするべきです。

中核となるITサービス

当社ではセキュリティやコンジットサービスを制限する法的命令には概ね従いますが、権威DNS、再帰DNS/1.1.1.1、WARPなどのITの中核となるサービスについては、より高いハードルを設けています。これらのサービスの課題は、サービスに対する制限が本質的にグローバルであることです。簡単に1つの法域だけを制限することはできないため、最も制限の厳しい法律によって世界的に適用されることになります。

当社は、これらの中核的なITサービスへのアクセスを制限しようとする法的命令に、たとえ適用対象が当社の無料顧客のみであったとしても、一般的に異議を唱えたり、上訴を行ってきました。そうすることで、規制当局や裁判所が懸念しているコンテンツを制限する、その目的により合った方法を提案することができるのです。

残念ながら、主に著作権者がある管轄区域で判決を得て、中核となるITサービスを終了させ、そのコンテンツを事実上オフラインにするために全世界に適用させるような試みが、ますます一般的になってきています。繰り返しになりますが、私たちは、どのようなコンテンツがオンラインで許可されるかの管理を、最も制限的であろうとする司法権の手に委ねることは、危険な前例であると考えています。

これまでのところ、私たちは、これはインターネットを規制する正しい方法ではないことを主張し、これらの事例を覆すことにほぼ成功しています。この路線を維持することが、グローバルなインターネットの健全な運用の基本だと考えています。しかし、当社のセキュリティや中核的なインターネット技術サービス全体の裁量を示すたびに、これらの重要なケースにおける私たちの主張は弱くなります。

有料vs無料

Cloudflareは、上記のすべてのカテゴリーにおいて、無料と有料の両方のサービスを提供しています。繰り返しになりますが、大半のお客様は無料サービスを利用し、当社に対する支払いは一切ありません。

不正利用のプロセスで見られる懸念のほとんどは無料のお客様に関連していますが、当社ではお客様が無料か有料かによって調整された異なるポリシーを設けておりません。しかし、当社の価値がお金を払ってくれるお客様と正反対を向いている場合には、お客様から利益を得ないだけでなく、その収益を私たちの会社の価値を高め、お客様の価値感に対抗するために使うという、さらなる措置を講じるべきだと考えています。

例えば、LGBTQ+の権利に反対するサイトからDDoS軽減サービスの有料版を契約いただいた際、私たちはProudflareの社員リソースグループと協力してLGBTQ+の権利を支援する団体を特定し、いただいたサービス料金の100%をその団体に寄付しています。なぜなら、私たちはこのような取り組みをマーケティングのために行っているのではなく、私たちが道徳的に正しいと信じることに沿った取り組みを行っているからです。

法の支配

私たちは、自分たちがホストするコンテンツを制限する義務があるとは考えていますが、何をオンラインにして、何をオンラインにしないかを一般的に決定し、セキュリティや中核的なインターネットサービスを制限する政治的正当性を持っているとは考えていません。もしそのコンテンツが有害である場合、それを制限する正しい場所は法律上です。

また、サイバー攻撃によってネット上の情報が黙殺されるようなインターネットは、その目的がいくら共感できるものであったとしても、インターネットの荒廃であると考えています。そのため、当社のセキュリティサービスや中核的なITサービスを停止するタイミングの決定については、一般的な意見ではなく、法的手続きに基づいて判断します。

一部の人が主張するかもしれませんが、私たちは言論の自由を絶対視しているわけではありません。しかし、私たちは「法の支配」を信じています。世界中のさまざまな国や管轄区域が、それぞれの規範や法律に基づいて、どのようなコンテンツが許され、どのようなコンテンツが許されないかを決定します。私たちの義務を評価する際、私たちは、それらの法律が管轄区域に限定されていること、「ビジネスと人権に関する国連指導原則」に基づく人権尊重の義務と一致しているかどうかに注目します。

世界には権利を侵害するものが多く存在し、残念ながらネット上には非難されるべきコンテンツが多く存在します。私たちは、これらの権利の侵害の一部を解決することはできますが、すべてを解決することはできません。しかし、インターネットのセキュリティと機能を向上に取り組む過程で、インターネットが長期的な損害を引き起こさないようにする必要があるのです。

私たちは、これらの課題について、またサイバー攻撃からグローバルなインターネットを保護するための最善の方法について、引き続き話し合いを行っていきます。また、犯罪捜査のために合法的な法執行機関と協力し、その他私たちが信じる平等、人権、活動を支援するための資金やサービスを寄付し、自由で開かれたインターネットを守るために世界中の政策決定の場への参加を継続します。

Politiques et approche de Cloudflare en matière d’utilisation abusive

2022-08-31 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/cloudflares-abuse-policies-and-approach-fr-fr/

Politiques et approche de Cloudflare en matière d'utilisation abusive

Cloudflare a été fondée voilà près de douze ans. L’entreprise s’est développée et exploite aujourd’hui un réseau couvrant plus de 275 villes, dans plus de 100 pays. Elle possède des millions de clients, de petites entreprises et de développeurs individuels à quelque 30 % des entreprises du classement Fortune 500. Aujourd’hui, plus de 20 % du web dépend directement des services de Cloudflare.

Depuis notre lancement, notre portefeuille de services est devenu beaucoup plus complexe. Avec cette complexité, nous avons élaboré des politiques déterminant de quelle façon nous traitons l’utilisation abusive des différentes fonctionnalités de Cloudflare. De la même manière qu’une vaste plateforme comme Google dispose de différentes politiques en matière d’utilisation abusive pour son moteur de recherche, Gmail, YouTube et Blogger, Cloudflare a élaboré différentes politiques en matière d’utilisation abusive à mesure que de nouveaux produits ont été introduits.

Nous avons publié une mise à jour de notre approche de l’utilisation abusive l’année dernière, à l’adresse :

https://www.cloudflare.com/trust-hub/abuse-approach/

Cependant, puisque des questions ont été soulevées, nous avons pensé qu’il était judicieux de décrire ces politiques plus en détail ici.

Les politiques que nous avons élaborées reflètent les idées et les recommandations d’experts des droits de l’homme, de militants, d’universitaires et de régulateurs. Conformément à nos principes directeurs, nos politiques en matière d’utilisation abusive doivent être spécifiques au service utilisé. Ceci vise à assurer que toutes les dispositions que nous prenons reflètent la capacité à traiter le préjudice et à minimiser les conséquences indésirables. Nous pensons qu’une personne souhaitant déposer une plainte suite à une utilisation abusive doit disposer d’une procédure lui permettant de contacter les personnes les plus à même de traiter sa plainte de manière efficace et précise – de manière anonyme, si nécessaire. Et surtout, nous nous efforçons de toujours faire preuve de transparence au regard de nos politiques et des dispositions que nous prenons.

Les produits de Cloudflare

Cloudflare propose une vaste gamme de produits, qui sont généralement répartis en trois catégories : les produits d’hébergement (par ex., Cloudflare Pages, Cloudflare Stream, Workers KV, pages d’erreur personnalisées), les services de sécurité (par ex., atténuation des attaques DDoS, pare-feu d’applications web, Cloudflare Access, limitation du taux) et les services de technologie Internet essentiels (par ex., DNS de référence, DNS récursif/1.1.1.1, WARP). Pour une liste complète de nos produits et de leur correspondance avec ces catégories, vous pouvez consulter notre portail d’informations concernant l’utilisation abusive.

Comme nous le décrivons ci-dessous, nos politiques suivent une approche différente, produit par produit, dans chacune de ces catégories.

Produits d’hébergement

Les produits d’hébergement sont les produits pour lesquels Cloudflare est l’hôte final du contenu. Ces produits diffèrent de ceux pour lesquels nous fournissons simplement des services de sécurité ou de mise en cache temporaire, tandis que le contenu est hébergé ailleurs. Bien que de nombreuses personnes confondent nos produits de sécurité avec des services d’hébergement, nous disposons de politiques distinctes pour chacun. Puisque l’immense majorité des clients de Cloudflare n’utilise pas encore nos produits d’hébergement, les plaintes et actions suite à une utilisation abusive de ces produits sont actuellement relativement rares.

Notre décision de désactiver l’accès au contenu de produits d’hébergement entraîne fondamentalement la mise hors ligne de ce contenu, du moins jusqu’à ce qu’il soit republié ailleurs. Les produits d’hébergement sont réglementés par notre Politique d’hébergement de contenus acceptables. En vertu de cette politique, pour ces produits, nous pouvons supprimer ou désactiver l’accès à tout contenu qui, selon nous :

Contient, affiche, distribue ou encourage la création de contenu à caractère pédopornographique, ou exploite ou encourage de toute autre manière l’exploitation de mineurs.
Enfreint les droits de propriété intellectuelle.
A été jugé diffamatoire ou calomnieux à l’issue d’une procédure juridique appropriée.
Contribue à la distribution illégale de substances contrôlées.
Facilite la traite des êtres humains ou la prostitution, en violation de la loi.
Contient, installe ou diffuse un logiciel malveillant actif ou utilise notre plateforme pour la diffusion d’exploits (par ex., dans le cadre d’un système de commande et de contrôle).
Est de quelque autre manière illégal ou nuisible, ou viole les droits d’autrui ; ceci concerne notamment tout contenu divulguant des informations personnelles sensibles, incitant ou exploitant la violence contre les personnes ou les animaux ou cherchant à frauder le public.

Nous faisons preuve de discrétion quant à l’application de notre Politique d’hébergement de contenus acceptables, et nous cherchons généralement à appliquer les restrictions en matière de contenu de manière aussi précise que possible. Par exemple, si une plateforme de paniers d’achats comptant des millions de clients utilise Cloudflare Workers KV et l’un de ses clients enfreint notre politique d’hébergement de contenus acceptables, nous ne résilierons pas automatiquement l’utilisation de Cloudflare Workers KV pour l’ensemble de la plateforme.

Notre principe directeur est que les organisations les plus proches du contenu sont les mieux placées pour déterminer quels contenus sont abusifs. Il reconnaît également que des désactivations trop étendues peuvent avoir un impact indésirable considérable sur l’accès aux contenus en ligne.

Et de la sécurité

L’immense majorité des millions de clients de Cloudflare utilise uniquement les services de sécurité de l’entreprise. En tant qu’entreprise, Cloudflare a décidé, très tôt dans son histoire, qu’elle souhaitait rendre les outils de sécurité aussi largement disponibles que possible. Cela signifie que nous avons fourni de nombreux outils à titre gratuit ou à un coût minime, afin de limiter au mieux l’impact et l’efficacité d’un large éventail de cyberattaques. La plupart de nos clients ne nous versent aucun paiement.

Donner à chacun la possibilité de s’inscrire pour utiliser nos services en ligne reflète également notre conviction que les cyberattaques ne doivent non seulement pas être utilisées pour réduire au silence des groupes vulnérables, mais ne constituent par ailleurs pas un mécanisme approprié pour réagir aux contenus problématiques en ligne. Nous pensons que les cyberattaques, sous quelque forme que ce soit, devraient être reléguées aux oubliettes de l’histoire.

La décision de fournir des outils de sécurité à si grande échelle nous a contraints à réfléchir avec prudence au moment où nous mettrons fin, le cas échéant, à l’accès à ces services. Nous avons pris conscience que nous devions réfléchir à l’effet qu’aurait l’arrêt de ces services et à la possibilité d’établir des normes qui pourraient être appliquées de manière équitable, transparente et non discriminatoire, conformément aux principes des droits de l’homme.

Cela vaut non seulement pour le contenu au sujet duquel une plainte peut avoir été déposée, mais également pour le précédent que crée cette suppression. Notre conclusion, fondée sur les nombreuses conversations que nous avons eues et les discussions réfléchies au sein de la communauté, au sens large, est que la résiliation volontaire de l’accès aux services de protection contre les cyberattaques n’est pas la bonne approche.

Éviter un abus de pouvoir

Certains affirment que nous devrions mettre fin à ces services pour les contenus que nous considérons comme répréhensibles, afin que d’autres puissent lancer des attaques pour les mettre hors ligne. C’est l’équivalent de l’argument, dans le monde physique, selon lequel les pompiers ne devraient pas éteindre les incendies dans les maisons de personnes possédant pas une qualité morale suffisante. Que ce soit dans le monde physique ou en ligne, cela constitue un dangereux précédent qui, à long terme, est susceptible de nuire de manière disproportionnée aux communautés vulnérables et marginalisées.

Aujourd’hui, plus de 20 % du web utilise les services de sécurité de Cloudflare. Lorsque nous réfléchissons à nos politiques, nous devons être conscients de l’impact que nous avons et du précédent que nous créons pour l’Internet dans son ensemble. La résiliation des services de sécurité pour des contenus que notre équipe juge personnellement dégoûtants et immoraux serait le choix le plus plébiscité. À long terme, toutefois, de tels choix rendent plus difficile la protection contre les attaques contre des contenus soutenant des voix opprimées et marginalisées.

Affiner notre politique en fonction de ce que nous avons appris

Ceci n’a rien d’hypothétique. Des milliers de fois par jour, nous recevons des appels nous demandant de résilier les services de sécurité en raison de contenus qu’une personne a signalés comme offensants. La plupart de ces demandes ne sont jamais évoquées dans l’actualité. La plupart du temps, ces décisions ne sont pas en contradiction avec nos opinions morales. Pourtant, à deux reprises dans le passé, nous avons décidé d’exclure des contenus de nos services de sécurité parce que nous les trouvions répréhensibles. En 2017, nous avons désactivé le site de trollage néonazi The Daily Stormer. Et en 2019, nous avons désactivé le forum consacré aux théories du complot 8chan.

Dans une réaction profondément troublante, après ces deux résiliations, nous avons constaté une augmentation spectaculaire des demandes émanant de régimes autoritaires qui tentaient de nous faire résilier les services de sécurité d’organisations de défense des droits de l’homme, en citant souvent les termes de notre propre justification.

Depuis ces décisions, nous avons eu des discussions importantes avec les décideurs politiques du monde entier. Après ces discussions, nous avons conclu que le pouvoir de résilier les services de sécurité pour des sites n’était pas un pouvoir que devrait détenir Cloudflare, non pas parce que le contenu de ces sites n’était pas odieux (il l’était), mais parce que les services de sécurité s’apparentent fortement à des services publics sur Internet.

De la même manière que votre opérateur de téléphonie ne résiliera pas votre abonnement parce que vous tenez des propos horribles, racistes et sectaires, nous avons conclu, après avoir consulté des politiciens, des décideurs politiques et des experts, que résilier les services de sécurité parce que nous considérons que des contenus publiés sont méprisables est une mauvaise politique. Pour être clairs, ce n’est pas parce que nous l’avons fait auparavant, dans un nombre limité de cas, que nous avions raison lorsque nous l’avons fait. Ou que nous le referons un jour.

Cependant, cela ne signifie pas que Cloudflare ne peut pas jouer un rôle important dans la protection de personnes ciblées par d’autres individus sur Internet. Nous soutenons depuis longtemps les groupes de défense des droits de l’homme, les journalistes et d’autres entités particulièrement vulnérables en ligne par le biais de l’initiative Project Galileo. Project Galileo propose des services de cybersécurité gratuits aux organisations à but non lucratif et aux groupes de défense des droits qui contribuent à renforcer nos communautés.

Dans le cadre de l’initiative Project Athenian, nous jouons également un rôle dans la protection des systèmes électoraux aux États-Unis et à l’étranger. Les élections figurent parmi les domaines dans lesquels les systèmes d’administration doivent être fondamentalement dignes de confiance et neutres. Faire des choix concernant les contenus qui méritent ou non de bénéficier des services de sécurité, en particulier d’une manière qui pourrait être interprétée comme politique, compromettrait notre capacité à assurer une protection fiable de l’infrastructure électorale.

Réalités réglementaires

Nos politiques répondent également aux réalités réglementaires. Les lois en matière de réglementation des contenus d’Internet adoptées au cours des cinq dernières années dans le monde entier ont largement établi une distinction entre les services qui hébergent des contenus et ceux qui fournissent des services de sécurité et d’acheminement. Même lorsque ces réglementations imposent aux plateformes ou aux hébergeurs l’obligation de modérer les contenus, elles exemptent les services de sécurité et d’acheminement de jouer le rôle de modérateur sans procédure juridique. Il s’agit d’une réglementation raisonnable, issue d’un processus réglementaire approfondi.

Nos politiques suivent ces orientations réglementaires mûrement réfléchies. Nous empêchons l’utilisation des services de sécurité par certaines organisations et personnes sanctionnées. Nous résilions également les services de sécurité en cas de contenus illégaux aux États-Unis, où se trouve le siège de Cloudflare. Cela inclut les contenus à caractère pédopornographique, ainsi que les contenus soumis à la loi FOSTA (Fight Online Sex Trafficking Act). Toutefois, nous pensons que les cyberattaques sont une chose dont chacun devrait être protégé, même si nous sommes fondamentalement en désaccord avec les contenus concernés.

Dans le respect de la primauté du droit et de l’équité procédurale, nous nous conformons à la procédure juridique lorsque nous contrôlons les services de sécurité. Nous restreindrons l’accès aux contenus dans les zones géographiques où nous avons reçu des ordonnances juridiques à cet effet. Par exemple, si un tribunal d’un pays interdit l’accès à certains contenus, nous restreindrons généralement l’accès à ces contenus dans ce pays, conformément à l’ordonnance de ce tribunal. Dans de nombreux cas, cela limitera la possibilité d’accéder aux contenus concernés dans le pays. Cependant, nous reconnaissons que ce n’est pas parce que des contenus sont illégaux dans une juridiction qu’ils le sont dans une autre. C’est pourquoi nous adaptons précisément ces restrictions, afin qu’elles correspondent à la juridiction du tribunal ou de l’autorité juridique.

Si nous respectons les procédures juridiques, nous pensons également que la transparence est d’une importance capitale. À cette fin, dans tous les endroits où sont imposées ces restrictions relatives aux contenus, nous essayons d’établir un lien avec l’ordonnance juridique particulière ayant exigé la restriction des contenus. Cette transparence est nécessaire pour que les personnes puissent s’impliquer dans le processus juridique et législatif. Nous trouvons profondément troublant que les fournisseurs d’accès à Internet se conforment à des ordonnances juridiques en mettant des contenus sous séquestre, de manière invisible, sans fournir aux personnes qui tentent d’y accéder la moindre idée du régime juridique qui les interdit. La liberté d’expression peut être restreinte par la loi, mais l’application correcte de la primauté du droit exige que quiconque la restreint fasse preuve de transparence quant aux raisons de cette restriction.

Services technologiques fondamentaux d’Internet

Si nous nous conformons généralement aux ordonnances juridiques relatives à la restriction des services de sécurité et d’acheminement, nos exigences sont plus élevées lorsqu’il s’agit des services technologiques fondamentaux d’Internet, tels que DNS de référence, DNS récursif/1.1.1.1 et WARP. La difficulté de ces services est que les restrictions qui leur sont imposées sont de nature mondiale. Il est difficile de les restreindre dans une seule juridiction, et la loi la plus restrictive finit par s’appliquer au niveau mondial.

En règle générale, nous avons contesté ou fait appel des ordonnances juridiques qui tentent de restreindre l’accès à ces services technologiques fondamentaux d’Internet, même lorsqu’une décision s’appliquait uniquement à nos clients gratuits. Dans ces situations, nous tentons de suggérer aux régulateurs ou aux tribunaux des moyens plus adaptés pour restreindre les contenus qui les préoccupent.

Malheureusement, ces cas deviennent de plus en plus fréquents, tandis que les détenteurs de droits d’auteur tentent d’obtenir une décision dans une juridiction et de la faire appliquer dans le monde entier, dans le but de mettre fin aux services technologiques fondamentaux d’Internet et d’obtenir la suppression effective de contenus. Une fois encore, nous pensons qu’il s’agit d’un dangereux précédent, qui place le contrôle des contenus autorisés en ligne entre les mains de toute juridiction qui acceptera d’être la plus restrictive.

Jusqu’à présent, nous avons largement réussi à faire valoir qu’il ne s’agit pas de la bonne façon de réglementer l’Internet, et sommes parvenus à faire annuler ces affaires. Nous pensons qu’il est fondamental de tenir cette ligne pour préserver le bon fonctionnement de l’Internet mondial. Toutefois, chaque démonstration de discrétion concernant nos services de sécurité ou nos services technologiques fondamentaux d’Internet affaiblit notre argumentaire dans ces affaires importantes.

Clients payants et clients gratuits

Cloudflare propose des services gratuits et payants dans toutes les catégories ci-dessus. Encore une fois, la majorité de nos clients utilisent nos services gratuits et ne nous versent aucun paiement.

Bien que la plupart des problèmes que nous constatons dans le cadre de notre processus de signalement d’utilisation abusive concernent nos clients gratuits, notre politique de modération ne diffère pas selon qu’un client a souscrit une offre gratuite ou payante. Nous pensons cependant que, dans les cas où nos valeurs sont diamétralement opposées à celles d’un client payant, nous devons prendre des dispositions supplémentaires, non seulement pour ne pas réaliser de profits avec ce client, mais également pour utiliser d’éventuelles recettes pour promouvoir les valeurs de notre entreprise et s’opposer aux siennes.

Par exemple, lorsqu’un site hostile aux droits des personnes LGBTQ+ a souscrit une version payante du service d’atténuation des attaques DDoS, nous avons travaillé avec le groupe d’employés Proudflare afin d’identifier une organisation qui soutient les droits des personnes LGBTQ+ et lui adresser un don équivalent à 100 % des frais facturés pour nos services. Nous n’évoquons pas publiquement ces initiatives et ne comptons pas le faire, parce que nous ne les prenons pas à des fins de marketing ; nous les prenons parce qu’elles sont en accord avec ce que nous pensons être moralement correct.

Primauté du droit

Si nous pensons avoir l’obligation de restreindre l’accès à des contenus que nous hébergeons nous-mêmes, nous ne pensons pas posséder la légitimité politique de déterminer, de manière générale, ce qui peut ou non être en ligne en restreignant la sécurité ou les services fondamentaux d’Internet. Si ces contenus sont malveillants, c’est à la législation qu’il incombe de les restreindre.

Nous pensons également qu’un Internet où les cyberattaques sont utilisées pour réduire au silence des contenus en ligne est un Internet défaillant, quelle que soit l’empathie que l’on peut avoir pour la finalité. C’est pourquoi nous nous fonderons sur la procédure juridique, et non sur l’opinion publique, pour guider nos décisions relatives à la résiliation de nos services de sécurité ou nos services technologiques Internet fondamentaux.

Malgré ce que peuvent prétendre certains, nous ne sommes pas des absolutistes de la liberté d’expression. Cependant, nous croyons à la primauté du droit. Différents pays et juridictions dans le monde détermineront quels contenus sont autorisés ou non en fonction de leurs normes et leurs lois. Pour évaluer nos obligations, nous vérifions si ces lois sont limitées à la juridiction concernée et si elles sont compatibles avec nos obligations de respecter les droits de l’homme, conformément aux Principes directeurs des Nations Unies relatifs aux entreprises et aux droits de l’homme.

Il subsiste encore de nombreuses injustices dans le monde et, malheureusement, beaucoup de contenus en ligne que nous trouvons répréhensibles. Nous pouvons résoudre certaines de ces injustices, mais nous ne pouvons pas les résoudre toutes. Toutefois, tandis que nous œuvrons pour améliorer la sécurité et le fonctionnement d’Internet, nous devons nous assurer de ne pas lui causer de dommages à long terme.Nous continuerons à discuter de ces défis et de la meilleure façon de protéger l’Internet mondial contre les cyberattaques. Nous continuerons également à coopérer avec les forces de l’ordre légitimes afin de soutenir les enquêtes sur des crimes, à faire don de fonds et de services dans le but de soutenir l’égalité, les droits de l’homme et les autres causes auxquelles nous croyons, et à participer à l’élaboration de politiques dans le monde entier, afin d’aider à préserver l’Internet libre et ouvert.

Cloudflare: Richtlinien zu & Umgang mit Regelverstößen

2022-08-31 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/cloudflares-abuse-policies-and-approach-de-de/

Cloudflare: Richtlinien zu & Umgang mit Regelverstößen

Cloudflare wurde vor fast zwölf Jahren gegründet. Wir haben ein Netzwerk aufgebaut, das mehr als 275 Städte in über 100 Ländern umfasst. Wir haben Millionen von Kunden: von kleinen Unternehmen und einzelnen Entwicklern bis hin zu etwa 30 Prozent der Fortune 500. Heute verlassen sich mehr als 20 Prozent des Internets direkt auf die Dienste von Cloudflare.

Seit unserer Gründung ist unser Serviceangebot im Laufe der Zeit immer komplexer geworden. Mit dieser Komplexität haben wir Richtlinien entwickelt, wie wir mit Regelverstößen bzw. dem Missbrauch der verschiedenen Cloudflare-Funktionen umgehen. So wie eine breite Plattform wie Google verschiedene Missbrauchsrichtlinien für die Suche, Gmail, YouTube und Blogger hat, hat Cloudflare mit der Einführung neuer Produkte verschiedene Richtlinien zum Umgang mit Regelverstößen entwickelt.

Wir haben unseren überarbeiteten Ansatz zum Umgang mit Regelverstößen im letzten Jahr hier veröffentlicht:

https://www.cloudflare.com/de-de/trust-hub/abuse-approach/

Da jedoch Fragen aufgetaucht sind, hielten wir es für sinnvoll, diese Richtlinien hier ausführlicher zu beschreiben.

Die von uns erstellten Richtlinien spiegeln Ideen und Empfehlungen von Menschenrechtsexperten, Aktivisten, Wissenschaftlern und Regulierungsbehörden wider. Unsere Leitprinzipien verlangen, dass die Richtlinien zum Umgang mit Regelverstößen spezifisch auf den in Anspruch genommenen Dienst zugeschnitten sind. So stellen wir sicher, dass alle Maßnahmen, die wir ergreifen, sowohl die Fähigkeit widerspiegeln, den Schaden zu beheben, als auch unbeabsichtigte Folgen zu minimieren. Wir sind der Meinung, dass jemand, dem eine Beschwerde über einen Regelverstoß vorgelegt wird, Zugang zu einem Verfahren zum Umgang mit Regelverstößen haben muss, um diejenigen zu erreichen, die sich am effektivsten und genauesten mit seiner Beschwerde befassen können – notfalls auch anonym. Und, was besonders wichtig ist, wir bemühen uns stets um Transparenz, sowohl was unsere Richtlinien als auch was unsere Maßnahmen betrifft.

Cloudflare-Produkte

Cloudflare bietet eine breite Palette von Produkten an, die sich im Allgemeinen in drei Kategorien einteilen lassen: Hosting-Produkte (z.B. Cloudflare Pages, Cloudflare Stream, Workers KV, Custom Error Pages), Sicherheitsservices (z.B. DDoS Mitigation, Web Application Firewall, Cloudflare Access, Rate Limiting) und zentrale Internet-Technologie-Services (z.B. Authoritative DNS, Recursive DNS/1.1.1.1, WARP). Eine vollständige Liste unserer Produkte und deren Zuordnung zu diesen Kategorien finden Sie in unserem Abuse Hub.

Wie im Folgenden beschrieben, verfolgen wir in jeder dieser Kategorien einen anderen Ansatz für jedes einzelne Produkt.

Hosting-Produkte

Hosting-Produkte sind Produkte, bei denen Cloudflare der endgültige Hoster der Inhalte ist. Dies unterscheidet sich von Produkten, bei denen wir lediglich Sicherheits- oder temporäre Caching-Dienste anbieten und der Inhalt anderswo gehostet wird. Obwohl viele Menschen unsere Sicherheitsprodukte mit Hosting-Diensten verwechseln, haben wir für beide unterschiedliche Richtlinien. Da die überwiegende Mehrheit der Cloudflare-Kunden unsere Hosting-Produkte noch nicht nutzt, sind Beschwerden über Regelverstöße und Klagen im Zusammenhang mit diesen Produkten derzeit relativ selten.

Unsere Entscheidung, den Zugriff auf Inhalte in Hosting-Produkten zu deaktivieren, hat grundsätzlich zur Folge, dass diese Inhalte offline genommen werden, zumindest bis sie an anderer Stelle neu veröffentlicht werden. Hosting-Produkte unterliegen unserer Richtlinie für zulässiges Hosting. Im Rahmen dieser Richtlinie können wir für diese Produkte den Zugang zu Inhalten entfernen oder sperren, wenn wir der Meinung sind, dass diese

Inhalte mit sexueller Gewalt an Kindern enthalten, anzeigen, verbreiten oder zur Erstellung von solchen Inhalten ermutigen oder die Ausbeutung von Minderjährigen anderweitig ausnutzen oder fördern.
gegen Rechte an geistigem Eigentum verstoßen.
in einem geeigneten Gerichtsverfahren als diffamierend oder verleumderisch eingestuft wurden.
beim illegalen Vertrieb bzw. der Verteilung von kontrollierten Substanzen mitwirken.
den Menschenhandel oder die Prostitution unter Verstoß gegen das Gesetz begünstigen.
aktive Malware enthalten, installieren oder verbreiten oder unsere Plattform für die Verbreitung von Exploits nutzen (z. B. als Teil eines Befehls- und Kontrollsystems).
anderweitig illegal oder schädlich sind oder die Rechte anderer verletzen, einschließlich Inhalten, die vertrauliche personenbezogene Informationen preisgeben, zur Gewalt gegen Menschen oder Tiere auffordern oder diese ausnutzen oder versuchen, die Öffentlichkeit zu betrügen.

Es liegt in unserem Ermessen, wie unsere Richtlinie für zulässiges Hosting durchgesetzt wird. Allgemein versuchen wir, inhaltliche Beschränkungen so spezifisch wie möglich anzuwenden. Wenn zum Beispiel eine Warenkorb-Plattform mit Millionen von Kunden Cloudflare Workers KV nutzt und einer ihrer Kunden gegen unsere Richtlinie für zulässiges Hosting verstößt, werden wir die Nutzung von Cloudflare Workers KV nicht automatisch für die gesamte Plattform beenden.

Unser Leitprinzip ist, dass die Organisationen, die den Inhalten am nächsten sind, am besten feststellen können, wann ein Inhalt einen Regelverstoß darstellt. Die Richtlinie berücksichtigt auch, dass eine zu weit gehende Entfernung von Inhalten erhebliche unbeabsichtigte Auswirkungen auf den Zugang zu Online-Inhalten haben kann.

Sicherheitsservices

Die überwiegende Mehrheit unserer Millionen von Cloudflare-Kunden nutzt ausschließlich unsere Sicherheitsdienste. Cloudflare hat sich bereits früh in seiner Geschichte dazu entschlossen, Sicherheitstools so weit wie möglich verfügbar zu machen. Dies bedeutete, dass wir viele Tools kostenlos oder zu minimalen Kosten zur Verfügung stellten, um die Auswirkungen und die Effektivität einer Vielzahl von Cyberangriffen bestmöglich zu begrenzen. Die meisten unserer Kunden zahlen nichts.

Dass wir jedem die Möglichkeit geben, sich online für unsere Dienste anzumelden, spiegelt auch unsere Ansicht wider, dass Cyberangriffe nicht nur nicht dazu verwendet werden sollten, gefährdete Gruppen zum Schweigen zu bringen, sondern auch nicht der geeignete Mechanismus sind, um gegen problematische Online-Inhalte vorzugehen. Wir sind der Meinung, dass Cyberangriffe, egal in welcher Form, endlich der Vergangenheit angehören sollten.

Weil wir Sicherheitstools so umfassend bereitstellen, mussten wir uns letztendlich fragen, wann oder ob wir den Zugang zu diesen Diensten überhaupt beenden würden. Uns wurde klar, dass wir darüber nachdenken mussten, wie sich die Kündigung bzw. Beendigung eines Services auswirken würde. Zudem mussten wir uns die Frage stellen, ob es eine Möglichkeit gibt, Standards festzulegen, die auf faire, transparente und nicht-diskriminierende Weise angewendet werden können und mit den Menschenrechtsprinzipien im Einklang stehen.

Dies gilt nicht nur für die Inhalte, für die eine Beschwerde eingereicht werden kann, sondern auch für den Präzedenzfall, den die Löschung schafft. Aufgrund der vielen Gespräche, die wir geführt haben, und der aufmerksamen Diskussion in der breiteren Öffentlichkeit sind wir zu dem Schluss gekommen, dass die freiwillige Beendigung des Zugangs zu Diensten, die vor Cyberangriffen schützen, nicht der richtige Ansatz ist.

Machtmissbrauch vermeiden

Einige argumentieren, dass wir diese Dienste für Inhalte, die wir für verwerflich halten, einstellen sollten, damit andere Angriffe starten können, um sie vom Netz zu nehmen. Diese Argumentation auf die physische Welt übertragen würde etwa bedeuten, dass die Feuerwehr nicht auf Brände in den Häusern von Menschen reagieren sollte, denen man nicht den nötigen moralischen Charakter bescheinigt. Sowohl in der physischen Welt als auch online ist dies ein gefährlicher Präzedenzfall, der auf lange Sicht höchstwahrscheinlich gefährdeten und benachteiligten Gemeinschaften unverhältnismäßig großen Schaden zufügen wird.

Heute nutzen mehr als 20 Prozent des Internets die Sicherheitsdienste von Cloudflare. Wenn wir unsere Richtlinien reflektieren, müssen wir darauf achten, welche Auswirkungen wir haben und welchen Präzedenzfall wir für das Internet als Ganzes schaffen. Das Beenden der Sicherheitsdienste für Inhalte, die unser Team persönlich als ekelhaft und unmoralisch empfindet, wäre die beliebteste Wahl. Aber auf lange Sicht wird es durch solche Entscheidungen schwieriger, Inhalte, die unterdrückte und benachteiligte Personen unterstützen, vor Angriffen zu schützen.

Präzisierung unserer Richtlinien auf der Grundlage unserer Erkenntnisse

Das ist keine theoretische Feststellung. Tagtäglich erhalten wir Tausende von Anrufen, dass wir Sicherheitsdienste aufgrund von Inhalten, die jemand als beleidigend meldet, beenden sollen. Meistens kommt das nicht in die Schlagzeilen. Meistens stehen diese Entscheidungen nicht im Widerspruch zu unseren moralischen Ansichten. Dennoch haben wir in der Vergangenheit zweimal beschlossen, Inhalte aus unseren Sicherheitsdiensten zu löschen, weil wir sie für verwerflich hielten. 2017 haben wir die Services für die Neonazi-Trollseite The Daily Stormer eingestellt. Und 2019 haben wir die Services für das auf Verschwörungstheorie fokussierte Forum 8chan eingestellt.

Danach erlebten wir eine zutiefst beunruhigende Entwicklung: Eine dramatische Zunahme autoritärer Regime, die versuchten, uns dazu zu bringen, die Sicherheitsdienste für Menschenrechtsorganisationen zu beenden. Dabei beriefen sie sich häufig wortwörtlich auf unsere eigene Rechtfertigung einer solchen Maßnahme.

Seit diesen Entscheidungen haben wir wichtige Gespräche mit politischen Entscheidungsträgern auf der ganzen Welt geführt. Aus diesen Gesprächen zogen wir den Schluss, dass die Befugnis, die Sicherheitsdienste für die Websites zu beenden, nicht in den Händen von Cloudflare liegen sollte. Nicht, weil der Inhalt dieser Seiten nicht abscheulich wäre – das war er –, sondern weil Sicherheitsdienste den Internetdienstleistern am ähnlichsten sind.

Ein Telefonanbieter kündigt Ihnen nicht den Anschluss, wenn Sie schreckliche, rassistische und menschenverachtende Dinge sagen. Analog sind wir in Absprache mit Politikern, Entscheidungsträgern und Experten zu dem Schluss gekommen, dass es die falsche Vorgehensweise wäre, Ihnen die Sicherheitsdienste abzuschalten, weil wir das, was Sie veröffentlichen, für verachtenswert halten. Um es klar zu sagen: Nur weil wir es in einer begrenzten Anzahl von Fällen getan haben, heißt das nicht, dass wir damit richtig lagen. Oder dass wir es jemals wieder tun werden.

Das bedeutet aber nicht, dass Cloudflare nicht eine wichtige Rolle beim Schutz derjenigen spielen kann, die von anderen im Internet angegriffen werden. Seit langem unterstützen wir Menschenrechtsgruppen, Journalisten und andere besonders gefährdete Organisationen im Internet durch das Projekt Galileo. Das Projekt Galileo bietet kostenlose Cybersicherheitsdienste für gemeinnützige Organisationen und Interessengruppen, die unsere Gemeinschaften stärken.

Durch das Projekt Athenian tragen wir auch zum Schutz von Wahlsystemen in den Vereinigten Staaten und anderen Ländern bei. Wahlen sind einer der Bereiche, in denen die Systeme, die sie verwalten, grundlegend vertrauenswürdig und neutral sein müssen. Entscheidungen darüber zu treffen, welche Inhalte Sicherheitsdienste verdienen oder nicht, insbesondere in einer Weise, die in irgendeiner Weise als politisch interpretiert werden könnte, würde unsere Fähigkeit untergraben, einen vertrauenswürdigen Schutz der Wahlinfrastruktur zu bieten.

Die regulatorische Realität

Unsere Richtlinien reagieren auch auf regulatorische Gegebenheiten. Die Gesetze zur Regulierung von Internetinhalten, die in den letzten fünf Jahren weltweit verabschiedet wurden, haben weitgehend eine Trennlinie zwischen Diensten, die Inhalte hosten, und solchen, die Sicherheits- und Durchleitungsdienste (Conduit-Dienste) anbieten, gezogen. Selbst wenn diese Vorschriften Plattformen oder Hosts dazu verpflichten, Inhalte zu moderieren, nehmen sie Sicherheits- und Durchleitungsdienste davon aus, die Rolle des Moderators ohne Gerichtsverfahren zu übernehmen. Dies ist eine vernünftige Regulierung, die auf einem gründlichen Regulierungsprozess beruht.

Unsere Richtlinien folgen diesen durchdachten regulatorischen Vorgaben. Wir verhindern, dass Sicherheitsdienste von sanktionierten Organisationen und Einzelpersonen genutzt werden. Wir kündigen auch Sicherheitsdienste für Inhalte, die in den Vereinigten Staaten – wo Cloudflare seinen Hauptsitz hat – illegal sind. Dazu gehört Material über sexuellen Kindesmissbrauch (Child Sexual Abuse Material, CSAM) sowie Inhalte, die dem Fight Online Sex Trafficking Act (FOSTA) unterliegen. Aber ansonsten sind wir der Meinung, dass jeder von Cyberangriffen verschont bleiben sollte. Selbst wenn wir mit dem Inhalt grundsätzlich nicht einverstanden sind.

Im Sinne der Rechtsstaatlichkeit und eines ordnungsgemäßen Verfahrens folgen wir den rechtlichen Verfahren zur Kontrolle der Sicherheitsdienste. Wir werden Inhalte in Regionen einschränken, in denen wir rechtliche Anordnungen dazu erhalten haben. Wenn beispielsweise ein Gericht in einem Land den Zugang zu bestimmten Inhalten verbietet, werden wir auf Anordnung dieses Gerichts den Zugang zu diesen Inhalten in diesem Land einschränken. Das schränkt in vielen Fällen den Zugriff auf die Inhalte in dem Land ein. Wir sind uns jedoch darüber im Klaren, dass Inhalte, die in einem Land illegal sind, es in einem anderen Land nicht sind. Daher passen wir diese Einschränkungen eng an die Zuständigkeit des Gerichts oder der Behörde an.

Wir halten uns zwar an die gesetzlichen Bestimmungen, glauben aber auch, dass Transparenz von entscheidender Bedeutung ist. Zu diesem Zweck versuchen wir, überall dort, wo diese Inhaltsbeschränkungen auferlegt werden, einen Link zu der jeweiligen Rechtsverordnung zu platzieren, die die Beschränkung des Inhalts verlangt. Diese Transparenz ist notwendig, damit die Menschen am Rechts- und Gesetzgebungsprozess teilnehmen können. Wir finden es sehr beunruhigend, wenn Internetanbieter gerichtlichen Anordnungen nachkommen, indem sie Inhalte unsichtbar sperren – ohne denjenigen, die versuchen, auf diese Inhalte zuzugreifen, darüber zu informieren, welche rechtliche Regelung dies verbietet. Die freie Meinungsäußerung kann per Gesetz eingeschränkt werden, aber die ordnungsgemäße Anwendung der Rechtsstaatlichkeit erfordert, dass derjenige, der sie einschränkt, transparent macht, warum er dies getan hat.

Zentrale Internet-Technologie-Dienste

Während wir im Allgemeinen gesetzliche Anordnungen zur Einschränkung von Sicherheits- und Conduit-Diensten befolgen, legen wir bei zentralen Internet-Technologiediensten wie Authoritative DNS, Recursive DNS/1.1.1.1, und WARP höhere Maßstäbe an. Die Herausforderung bei diesen Diensten besteht darin, dass die Beschränkungen für diese Dienste globaler Natur sind. Sie können sie nicht einfach nur in einem Land einschränken, so dass das restriktivste Gesetz schließlich weltweit gilt.

Wir haben in der Regel gerichtliche Anordnungen angefochten, die versuchen, den Zugang zu diesen zentralen Internet-Technologiediensten einzuschränken, selbst wenn eine Entscheidung nur für jene Kunden gilt, die unsere Dienste kostenlos nutzen. Auf diese Weise versuchen wir, den Regulierungsbehörden oder Gerichten maßgeschneiderte Möglichkeiten zur Beschränkung der Inhalte vorzuschlagen, die ihnen möglicherweise Sorgen bereiten.

Leider werden diese Fälle immer häufiger, in denen die Inhaber von Urheberrechten versuchen, ein Urteil in einer Gerichtsbarkeit zu erwirken, das dann weltweit gilt, um wichtige Internet-Technologiedienste abzuschalten und Inhalte praktisch aus dem Internet zu löschen. Auch hier sind wir der Meinung, dass dies ein gefährlicher Präzedenzfall ist, der die Kontrolle darüber, welche Inhalte online erlaubt sind, in die Hände derjenigen Gerichtsbarkeit legt, die bereit ist, am restriktivsten zu sein.

Bislang ist es uns weitgehend gelungen, diese Fälle zu kippen und Argumente dafür vorzubringen, dass dies nicht der richtige Weg ist, das Internet zu regulieren. Wir glauben, dass die Beibehaltung dieser Vorgehensweise für das gesunde Funktionieren des globalen Internets von grundlegender Bedeutung ist. Aber jeder Hinweis auf Diskretion in Bezug auf unsere Sicherheits- oder zentralen Internet-Technologiedienste schwächt unsere Argumentation in diesen wichtigen Fällen.

Bezahlt vs. kostenlos

Cloudflare bietet sowohl kostenlose als auch kostenpflichtige Dienste in allen oben genannten Kategorien an. Auch hier gilt, dass die meisten unserer Kunden unsere kostenlosen Dienste nutzen und uns nichts bezahlen.

Die meisten Bedenken, die wir bei unserem Prozess zum Umgang mit Regelverstößen feststellen, betreffen zwar unsere kostenlosen Kunden. Dennoch gibt es bei uns keine unterschiedlichen Moderationsrichtlinien, je nachdem, ob ein Kunde kostenloser oder zahlender Kunde ist. Wir sind jedoch der Meinung, dass wir in solchen Fällen, in denen unsere Werte einem zahlenden Kunden (bzw. dessen Inhalten und Ansichten) diametral entgegengesetzt sind, weitere Schritte unternehmen sollten, um nicht nur nicht von dem Kunden zu profitieren, sondern alle Erlöse zur Förderung der Werte unseres Unternehmens und gegen die des Kunden zu verwenden.

Als sich beispielsweise eine Website, die sich gegen die Rechte von LGBTQ+ aussprach, für eine kostenpflichtige Version des DDoS-Abwehrdienstes anmeldete, haben wir gemeinsam mit unserer Proudflare-Mitarbeitergruppe eine Organisation ermittelt, die sich für die Rechte von LGBTQ+ einsetzt, und 100 Prozent der Gebühren für unsere Dienste an sie gespendet. Wir sprechen nicht öffentlich über diese Bemühungen und werden dies auch nicht tun, denn wir setzen diese Maßnahmen nicht zu Marketingzwecken, sondern weil sie mit dem übereinstimmen, was wir für moralisch richtig halten.

Rechtsstaatlichkeit

Wir glauben zwar, dass wir verpflichtet sind, die Inhalte, die wir selbst hosten, zu beschränken. Allerdings sind wir nicht der Meinung, dass wir die politische Legitimation haben, generell zu bestimmen, was online ist und was nicht, indem wir die Sicherheit oder zentrale Internetdienste einschränken. Wenn diese Inhalte schädlich sind, sollten sie idealerweise gesetzlich eingeschränkt werden.

Wir glauben auch, dass ein Internet, in dem Cyberangriffe eingesetzt werden, um Inhalte und deren Verfasser zum Schweigen zu bringen, ein von Fehlern geplagtes, kaputtes Internet ist (egal wie viel Verständnis wir für die Absichten vielleicht haben mögen). Daher werden wir uns bei unseren Entscheidungen darüber, wann wir unsere Sicherheitsdienste oder unsere wichtigsten Internet-Technologiedienste einstellen, von rechtlichen Verfahren leiten lassen und nicht von der öffentlichen Meinung.

Entgegen der Behauptung einiger sind wir keine absoluten Verfechter der Meinungsfreiheit. Wir glauben jedoch an die Rechtsstaatlichkeit. Verschiedene Länder und Gerichtsbarkeiten auf der ganzen Welt werden auf der Grundlage ihrer eigenen Normen und Gesetze bestimmen, welche Inhalte erlaubt sind und welche nicht. Bei der Beurteilung unserer Verpflichtungen achten wir darauf, ob diese Gesetze auf die jeweilige Rechtsordnung beschränkt sind und mit unseren Verpflichtungen zur Achtung der Menschenrechte gemäß den United Nations Guiding Principles on Business and Human Rights übereinstimmen.

Es gibt nach wie vor viel Ungerechtigkeit in der Welt und leider auch viele Inhalte im Internet, die wir verwerflich finden. Wir können einige dieser Ungerechtigkeiten lösen, aber nicht alle. Aber bei unseren Bemühungen, die Sicherheit und Funktionsweise des Internets zu verbessern, müssen wir sicherstellen, dass wir ihm nicht langfristig schaden.

Wir werden weiterhin über diese Herausforderungen diskutieren und darüber, wie wir das globale Internet am besten vor Cyberangriffen schützen können. Wir werden auch weiterhin mit legitimen Strafverfolgungsbehörden zusammenarbeiten, um bei der Aufklärung von Straftaten zu helfen, Gelder und Dienstleistungen zu spenden, um Gleichberechtigung, Menschenrechte und andere Anliegen, an die wir glauben, zu unterstützen, und uns an politischen Entscheidungen auf der ganzen Welt zu beteiligen, um das freie und offene Internet zu erhalten.

Cloudflare 的滥用处理政策和方法

2022-08-31 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/cloudflares-abuse-policies-and-approach-zh-cn/

Cloudflare 的滥用处理政策和方法

Cloudflare 创立于近 12 年前。我们不断发展扩大，目前运营的网络覆盖 100 多个国家/地区的超过 275 个城市。我们拥有数百万客户，既有小型企业和个人开发者，也有大约 30% 的财富 500 强公司。今天，超过 20% 的 Web 内容直接依赖 Cloudflare 的服务。

自创立以来，我们的服务集复杂程度已大幅提高。鉴于这种复杂性，针对不同 Cloudflare 功能，我们制定了处理滥用的政策。正如 Google 等广泛的平台对搜索、Gmail、Youtube 和博客等服务有不同的滥用政策一样，Cloudflare 也在推出新产品的同时制定了不同的滥用处理政策。

去年，我们发布了最新的滥用处理方法，网址是：

https://www.cloudflare.com/trust-hub/abuse-approach/

然而，由于出现了一些问题，我们认为有必要在此更详细地说明一下这些政策。

我们制定的政策反映了人权专家、活动人士、学者和监管机构的想法和建议。我们的指导原则要求针对所用的服务制定专门的滥用政策。这是为了确保，我们所采取的任何行动既能反映应对伤害的能力，也能最大程度减轻意外后果。我们认为，必须提供一个滥用投诉程序，以便有关举报到达能够最有效、最准确地进行处理的人士，并且能够在必要时以匿名方式举报。至关重要的是，我们始终努力使我们的政策和行动透明公开。

Cloudflare 的产品

Cloudflare 提供广泛的产品，大致归为三类：托管产品（例如 Cloudflare Pages，Cloudflare Stream，Workers KV，自定义错误页面），安全服务（例如 DDoS 缓解, Web 应用程序防火墙，Cloudflare Access，速率限制），以及核心互联网技术服务（例如权威 DNS，递归 DNS/1.1.1.1，WARP）。完整的产品列表及归属类别，请参见滥用处理中心（Abuse Hub）。

如下所述，我们的政策对各类别中的每种产品采取不同的方式。

托管产品

托管产品是指 Cloudflare 为内容最终所在主机的产品。这不同于 Cloudflare 仅提供安全或临时缓存服务，而内容托管于其他地方的产品。尽管很多人将我们的安全产品和托管服务相混淆，但我们对两者采取截然不同的政策。因为 Cloudflare 的绝大多数客户尚未使用我们的托管产品，涉及这些产品的滥用投诉和行动目前相对较少。

如果我们决定禁止对托管产品的访问，则会从根本上导致该等内容下线，至少直至该内容在其他地方重新发布为止。托管产品需要遵守我们的可接受托管政策（Acceptable Hosting Policy）。根据该政策，对于这些产品，如果我们相信存在如下情况，即可移除内容或禁止对该内容的访问：

包含，显示，分发或鼓励儿童性虐待材料的创建，或以其他方式利用或促进对未成年人的利用。
侵犯知识产权。
已被适当的法律程序判定为诽谤。
参与受管制物质的非法分销。
为非法贩卖人口或卖淫提供便利。
包含、安装或传播任何活跃的恶意软件，或使用我们的平台实施漏洞攻击（例如作为命令和控制系统的一部分）。
违法、有害或侵犯他人权利，包括披露敏感的个人信息，煽动或利用对人或动物的暴力，或试图欺骗公众。

关于如何执行我们的可接受托管政策，我们保留酌情裁量权，并在一般情况下寻求以尽可能准确的方式应用内容限制。例如，如果一个拥有数百万客户的购物车平台使用 Cloudflare Workers KV，其中一位客户违反了我们的可接受托管政策，我们将不会自动终止整个平台的 Cloudflare Workers KV 使用。

我们的指导原则是，最接近内容的组织最适合确定何时内容存在滥用问题。该指导原则也认为，过于宽泛的下线会对在线内容的访问产生重大的意外影响。

安全服务

Cloudflare 数百万用户中绝大部分仅使用我们的安全服务。Cloudflare 成立后不久就决定尽可能广泛地提供安全工具。这意味着我们免费或以最低成本提供许多工具，旨在最大程度地限制广泛网络攻击的影响和效果。我们的大多数客户不用支付分文。

让每个人都能够在线注册我们的服务，也反映了我们的观点：即网络攻击不仅不应该用于压制弱势群体，也不是解决有问题在线内容的适当机制。我们认为，任何形式的网络攻击都应该被扔进历史的垃圾箱。

如此广泛地提供安全工具的决定意味着，我们必须仔细考虑何时或是否终止对这些服务的访问。我们认识到，我们需要仔细考虑终止将会产生什么影响，以及是否有办法制定符合人权原则的标准，并以公平、透明和非歧视的方式实施。

这不仅适用于可能被投诉的内容，也适用于下线内容所设定的先例。根据我们进行的大量对话，以及在更广泛社区进行的深入讨论，我们的结论是，自愿停止提供防御网络攻击的服务并非正确的方式。

避免滥用权力

有人认为，如果我们发现内容应该受到谴责，我们就应该停止向其提供服务，以便其他人能发动攻击并导致其下线。这相当于说，在不具备足够道德品质的人家中失火时，消防部门置之不理。无论是在现实世界还是网络世界，这都是一个危险的先例，而且从长远来看，这很可能对弱势和边缘化的社区造成特别大的伤害。

今天，超过 20% 的 Web 内容使用 Cloudflare 的安全服务。在考虑我们的政策时，需要注意我们对整个互联网的影响和设定的先例。对我们团队自己认为恶心和不道德的内容终止安全服务，这将是受欢迎的选择。但长期而言，这种选择导致更难保护那些支持受压迫和边缘化声音的内容以防攻击。

根据所学知识改进政策

这并不是理论。我们每天都会接到数千个电话，要求我们对某人报告的冒犯性内容终止安全服务。这些情况大部分不会成为新闻。大多数时候，这些决定并不与我们的道德观点相冲突。然而，曾经有两次，我们因发现内容应受谴责而停止向其提供安全服务。在 2017 年，我们终止了新纳粹网站 The Daily Stormer。在 2019 年，我们终止了阴谋论论坛 8chan。

令人深感不安的是，在以上两次终止之后，专制政权试图让我们停止向人权组织提供安全服务支持的情况急剧增加，并往往引用我们自己的理由。

自从上述决定以后，我们与世界各地政策制定者进行了大量讨论。从这些讨论中我们得出结论，Cloudflare 不应该拥有终止这些网站安全服务的权力。这并不是因为这些网站的内容不令人厌恶——确实如此——而是因为安全服务与互联网服务最为相似。

电话公司不会因为你说了可怕、种族主义、偏执的事情而终止你的电话服务。同样，经过与政客、政策制定者和专家的磋商，我们的结论是，因为我们认为你发布的内容卑劣可耻而关闭安全服务是错误的政策。需要明确的是，仅仅因为我们之前在有限的情况下这样做过，并不意味着我们这样做的时候是正确的。也不代表我们会再次这样做。

但这并不意味着 Cloudflare 在保护互联网上受攻击者方面不能发挥重要作用。通过 Project Galileo，我们长期支持在线人权组织、记者和其他特别脆弱的实体。Project Galileo 为非营利组织和倡导团体提供免费的网络安全服务，以帮助加强我们的社区。

通过 Athenian Project，我们也在保护美国和国外的选举制度方面发挥了作用。选举是管理选举的制度需要从根本上是值得信赖和中立的领域之一。选择哪些内容值得或不值得获得安全服务，特别是任何可能被解释为政治的内容，都会削弱我们为选举基础设施提供可信保护的能力。

监管现实

我们的政策也对监管现实做出反应。过去五年来，世界各地通过的互联网内容监管法律普遍在内容托管服务与安全、传输服务之间划清界线。尽管这些法律规定了平台或托管服务商监管内容的义务，但不要求安全和传输服务在未经法律程序的情况下扮演审核者的角色。这是产生于慎密监管过程的合理监管。

我们的政策遵循这一经过深思熟虑的监管指导方针。我们阻止安全服务被受到制裁的组织和个人使用。我们也会对在美国（Cloudflare 总部所在地）被视为违法的内容提供安全服务。其中包括儿童性虐待材料（CSAM）以及受《打击网络性交易法案》（FOSTA）制约的内容。但除此以外，我们认为每个人都应该免受网络攻击。即使我们从根本上不认同这些内容。

就法规和正当程序而言，我们遵循管制安全服务的法律程序。我们将在收到法律命令的地理区域限制相关内容。例如，如果一个国家的法院禁止访问某些内容，那么，按照该法院的命令，我们通常会在该国限制对相关内容的访问。在很多情况下，这将导致在该国对相关内容的访问将受到限制。但我们认识到，仅仅因为内容在一个司法管辖区是非法的，并不意味着它在另一个司法管辖区也是非法的，因此我们会根据法院或执法当局的司法管辖范围来准确地实施限制。

在遵循法律程序的同时，我们也认为透明度至关重要。为此，无论在何处施加这些内容限制，我们都试图将其与要求限制内容的特定法律命令关联起来。这种透明度对于人们参与法律和立法程序是必要的。互联网服务提供商（ISP）按照法院命令暗中封锁内容，让尝试访问内容的人无法得知什么法律制度禁止有关内容，这种做法让我们深感不安。言论可以被法律限制，但要恰当地运用法治，无论谁限制言论，都要公开其原因。

核心互联网技术服务

虽然我们通常会遵守限制安全和传输服务的法律命令，但我们对核心互联网技术服务有更高的要求，如权威 DNS、递归 DNS/1.1.1.1 WARP。这些服务的挑战在于，对它们的限制是全球性的。无法简单地仅在某个司法管辖区限制这些服务，因为这样会导致最严格的法律应用到全球范围。

我们通常对试图限制使用这些核心互联网技术服务的法律命令提出挑战或上诉，即使某个裁决只针对我们的免费客户。在这个过程中，我们试图向监管机构或法院建议更有针对性的方法来限制他们可能关注的内容。

到目前为止，我们基本能成功证明这不是监管互联网的正确方式，并推翻了这些案件。我们认为，坚持这一原则对全球互联网的健康运行至关重要。然而，每次就我们的安全或核心互联网技术服务进行酌情裁量，都会削弱我们在这些重要案件中的论据。

付费与免费

对于上述所有类别，Cloudflare 同时提供免费和付费服务。同样，我们的大部分客户免费使用我们的服务，无需支付任何费用。

尽管我们在滥用投诉程序中看到的大多数问题都与免费客户有关，但我们并没有根据客户是免费还是付费制定不同的审核策略。然而，我们确实认为，在我们的价值观与某个付费客户截然相反的情况下，我们应该采取进一步措施，以确保非但不从该客户获取利益，还要利用任何收益来促进本公司的价值观并反对该客户的价值观。

例如，当一个反对 LGBTQ+ 权利的网站注册付费版 DDoS 缓解服务时，我们与 Proudflare 员工资源组合作物色了一个支持 LGBTQ+ 权利的组织，并将我们的 100% 服务费用捐赠给该组织。无论是现在和将来，我们都不会公开讨论这些努力，因为我们这样做不是为了营销目的，而是因为其符合我们的道德观念。

法治

虽然我们有义务对自己托管的内容进行限制，但我们并不认为我们拥有通过限制安全或核心互联网技术服务来确定什么在线、什么不在线的政治合法性。如果内容是有害的，法律是对其进行限制的适当方式。

我们还认为，使用网络攻击来压制在线内容的互联网是病态的，无论我们对其目的有多同情。因此，就何时终止我们的安全服务或核心互联网技术服务做出决定时，我们将参考法律程序，而非公众意见。

不管某些人怎么说，我们并不是言论自由绝对主义者。然而，我们的确相信法治。世界上不同国家和司法管辖区会根据自己的规范和法律来决定允许哪些内容，禁止哪些内容。在评估我们的义务时，我们会考虑那些法律是否仅限于该司法管辖区，是否符合我们按照《联合国工商业与人权指导原则》尊重人权的义务。

世界上仍然存在诸多不公正的问题，而且不幸的是，我们发现网上有大量内容应受到谴责。我们可以解决其中一些不公正问题，但无法解决所有不公正问题。但是，在努力改善互联网安全和功能的过程中，我们需要确保不会对其造成长期伤害。

我们将继续讨论这些挑战，以及如何最好地保护全球互联网免受网络攻击。我们还将继续与执法部门合作以帮助调查犯罪，捐助款项和服务以支持平等、人权和我们相信的其他事业，并参与世界各地的政策制定过程，以帮助保护自由和开放的互联网。

The mechanics of a sophisticated phishing scam and how we stopped it

2022-08-09 Matthew Prince

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/2022-07-sms-phishing-attacks/

The mechanics of a sophisticated phishing scam and how we stopped it

Yesterday, August 8, 2022, Twilio shared that they’d been compromised by a targeted phishing attack. Around the same time as Twilio was attacked, we saw an attack with very similar characteristics also targeting Cloudflare’s employees. While individual employees did fall for the phishing messages, we were able to thwart the attack through our own use of Cloudflare One products, and physical security keys issued to every employee that are required to access all our applications.

We have confirmed that no Cloudflare systems were compromised. Our Cloudforce One threat intelligence team was able to perform additional analysis to further dissect the mechanism of the attack and gather critical evidence to assist in tracking down the attacker.

This was a sophisticated attack targeting employees and systems in such a way that we believe most organizations would be likely to be breached. Given that the attacker is targeting multiple organizations, we wanted to share here a rundown of exactly what we saw in order to help other companies recognize and mitigate this attack.

Targeted Text Messages

On July 20, 2022, the Cloudflare Security team received reports of employees receiving legitimate-looking text messages pointing to what appeared to be a Cloudflare Okta login page. The messages began at 2022-07-22 22:50 UTC. Over the course of less than 1 minute, at least 76 employees received text messages on their personal and work phones. Some messages were also sent to the employee’s family members. We have not yet been able to determine how the attacker assembled the list of employee’s phone numbers but have reviewed access logs to our employee directory services and have found no sign of compromise.

Cloudflare runs a 24×7 Security Incident Response Team (SIRT). Every Cloudflare employee is trained to report anything that is suspicious to the SIRT. More than 90 percent of the reports to SIRT turn out to not be threats. Employees are encouraged to report anything and never discouraged from over-reporting. In this case, however, the reports to SIRT were a real threat.

The text messages received by employees looked like this:

They came from four phone numbers associated with T-Mobile-issued SIM cards: (754) 268-9387, (205) 946-7573, (754) 364-6683 and (561) 524-5989. They pointed to an official-looking domain: cloudflare-okta.com. That domain had been registered via Porkbun, a domain registrar, at 2022-07-20 22:13:04 UTC — less than 40 minutes before the phishing campaign began.

Cloudflare built our secure registrar product in part to be able to monitor when domains using the Cloudflare brand were registered and get them shut down. However, because this domain was registered so recently, it had not yet been published as a new .com registration, so our systems did not detect its registration and our team had not yet moved to terminate it.

If you clicked on the link it took you to a phishing page. The phishing page was hosted on DigitalOcean and looked like this:

Cloudflare uses Okta as our identity provider. The phishing page was designed to look identical to a legitimate Okta login page. The phishing page prompted anyone who visited it for their username and password.

Real-Time Phishing

We were able to analyze the payload of the phishing attack based on what our employees received as well as its content being posted to services like VirusTotal by other companies that had been attacked. When the phishing page was completed by a victim, the credentials were immediately relayed to the attacker via the messaging service Telegram. This real-time relay was important because the phishing page would also prompt for a Time-based One Time Password (TOTP) code.

Presumably, the attacker would receive the credentials in real-time, enter them in a victim company’s actual login page, and, for many organizations that would generate a code sent to the employee via SMS or displayed on a password generator. The employee would then enter the TOTP code on the phishing site, and it too would be relayed to the attacker. The attacker could then, before the TOTP code expired, use it to access the company’s actual login page — defeating most two-factor authentication implementations.

Protected Even If Not Perfect

We confirmed that three Cloudflare employees fell for the phishing message and entered their credentials. However, Cloudflare does not use TOTP codes. Instead, every employee at the company is issued a FIDO2-compliant security key from a vendor like YubiKey. Since the hard keys are tied to users and implement origin binding, even a sophisticated, real-time phishing operation like this cannot gather the information necessary to log in to any of our systems. While the attacker attempted to log in to our systems with the compromised username and password credentials, they could not get past the hard key requirement.

But this phishing page was not simply after credentials and TOTP codes. If someone made it past those steps, the phishing page then initiated the download of a phishing payload which included AnyDesk’s remote access software. That software, if installed, would allow an attacker to control the victim’s machine remotely. We confirmed that none of our team members got to this step. If they had, however, our endpoint security would have stopped the installation of the remote access software.

How Did We Respond?

The main response actions we took for this incident were:

1. Block the phishing domain using Cloudflare Gateway

Cloudflare Gateway is a Secure Web Gateway solution providing threat and data protection with DNS / HTTP filtering and natively-integrated Zero Trust. We use this solution internally to proactively identify malicious domains and block them. Our team added the malicious domain to Cloudflare Gateway to block all employees from accessing it.

Gateway’s automatic detection of malicious domains also identified the domain and blocked it, but the fact that it was registered and messages were sent within such a short interval of time meant that the system hadn’t automatically taken action before some employees had clicked on the links. Given this incident we are working to speed up how quickly malicious domains are identified and blocked. We’re also implementing controls on access to newly registered domains which we offer to customers but had not implemented ourselves.

2. Identify all impacted Cloudflare employees and reset compromised credentials

We were able to compare recipients of the phishing texts to login activity and identify threat-actor attempts to authenticate to our employee accounts. We identified login attempts blocked due to the hard key (U2F) requirements indicating that the correct password was used, but the second factor could not be verified. For the three of our employees’ credentials were leaked, we reset their credentials and any active sessions and initiated scans of their devices.

3. Identify and take down threat-actor infrastructure

The threat actor’s phishing domain was newly registered via Porkbun, and hosted on DigitalOcean. The phishing domain used to target Cloudflare was set up less than an hour before the initial phishing wave. The site had a Nuxt.js frontend, and a Django backend. We worked with DigitalOcean to shut down the attacker’s server. We also worked with Porkbun to seize control of the malicious domain.

From the failed sign-in attempts we were able to determine that the threat actor was leveraging Mullvad VPN software and distinctively using the Google Chrome browser on a Windows 10 machine. The VPN IP addresses used by the attacker were 198.54.132.88, and 198.54.135.222. Those IPs are assigned to Tzulo, a US-based dedicated server provider whose website claims they have servers located in Los Angeles and Chicago. It appears, actually, that the first was actually running on a server in the Toronto area and the latter on a server in the Washington, DC area. We blocked these IPs from accessing any of our services.

4. Update detections to identify any subsequent attack attempts

With what we were able to uncover about this attack, we incorporated additional signals to our already existing detections to specifically identify this threat-actor. At the time of writing we have not observed any additional waves targeting our employees. However, intelligence from the server indicated the attacker was targeting other organizations, including Twilio. We reached out to these other organizations and shared intelligence on the attack.

5. Audit service access logs for any additional indications of attack

Following the attack, we screened all our system logs for any additional fingerprints from this particular attacker. Given Cloudflare Access serves as the central control point for all Cloudflare applications, we can search the logs for any indication the attacker may have breached any systems. Given employees’ phones were targeted, we also carefully reviewed the logs of our employee directory providers. We did not find any evidence of compromise.

Lessons Learned and Additional Steps We’re Taking

We learn from every attack. Even though the attacker was not successful, we are making additional adjustments from what we’ve learned. We’re adjusting the settings for Cloudflare Gateway to restrict or sandbox access to sites running on domains that were registered within the last 24 hours. We will also run any non-whitelisted sites containing terms such as “cloudflare” “okta” “sso” and “2fa” through our browser isolation technology. We are also increasingly using Area 1’s phish-identification technology to scan the web and look for any pages that are designed to target Cloudflare. Finally, we’re tightening up our Access implementation to prevent any logins from unknown VPNs, residential proxies, and infrastructure providers. All of these are standard features of the same products we offer to customers.

The attack also reinforced the importance of three things we’re doing well. First, requiring hard keys for access to all applications. Like Google, we have not seen any successful phishing attacks since rolling hard keys out. Tools like Cloudflare Access made it easy to support hard keys even across legacy applications. If you’re an organization interested in how we rolled out hard keys, reach out to [email protected] and our security team would be happy to share the best practices we learned through this process.

Second, using Cloudflare’s own technology to protect our employees and systems. Cloudflare One’s solutions like Access and Gateway were critical to staying ahead of this attack. We configured our Access implementation to require hard keys for every application. It also creates a central logging location for all application authentications. And, if ever necessary, a place from which we can kill the sessions of a potentially compromised employee. Gateway allows us the ability to shut down malicious sites like this one quickly and understand what employees may have fallen for the attack. These are all functionalities that we make available to Cloudflare customers as part of our Cloudflare One suite and this attack demonstrates how effective they can.

Third, having a paranoid but blame-free culture is critical for security. The three employees who fell for the phishing scam were not reprimanded. We’re all human and we make mistakes. It’s critically important that when we do, we report them and don’t cover them up. This incident provided another example of why security is part of every team member at Cloudflare’s job.

Detailed Timeline of Events

2022-07-20 22:49 UTC	Attacker sends out 100+ SMS messages to Cloudflare employees and their families.
2022-07-20 22:50 UTC	Employees begin reporting SMS messages to Cloudflare Security team.
2022-07-20 22:52 UTC	Verify that the attacker’s domain is blocked in Cloudflare Gateway for corporate devices.
2022-07-20 22:58 UTC	Warning communication sent to all employees across chat and email.
2022-07-20 22:50 UTC to 2022-07-20 23:26 UTC	Monitor telemetry in the Okta System log & Cloudflare Gateway HTTP logs to locate credential compromise. Clear login sessions and suspend accounts on discovery.
2022-07-20 23:26 UTC	Phishing site is taken down by the hosting provider.
2022-07-20 23:37 UTC	Reset leaked employee credentials.
2022-07-21 00:15 UTC	Deep dive into attacker infrastructure and capabilities.

Indicators of compromise

Value	Type	Context and MITRE Mapping
cloudflare-okta[.]com hosted on 147[.]182[.]132[.]52	Phishing URL	T1566.002: Phishing: Spear Phishing Link sent to users.
64547b7a4a9de8af79ff0eefadde2aed10c17f9d8f9a2465c0110c848d85317a	SHA-256	T1219: Remote Access Software being distributed by the threat actor

What You Can Do

If you are similar attacks in your environment, please don’t hesitate to reach out to [email protected], and we’re happy to share best practices on how to keep your business secure. Finally, if you want to work on detecting and mitigating the next attacks with us? We’re hiring on our Detection and Response team, come join us!