All posts by Matthew Prince

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

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

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

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

Cloudflare’s 2023 Annual Founders’ Letter

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.

Cloudflare’s 2023 Annual Founders’ Letter

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.

Cloudflare’s 2023 Annual Founders’ Letter

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.

Cloudflare’s 2023 Annual Founders’ Letter

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.

Cloudflare’s 2023 Annual Founders’ Letter

(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.

Cloudflare’s 2023 Annual Founders’ Letter

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.

Cloudflare’s 2023 Annual Founders’ Letter
Cloudflare’s 2023 Annual Founders’ Letter

Welcome to Cloudflare’s Impact Week

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

Welcome to Cloudflare’s 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.

Welcome to Cloudflare’s Impact Week

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.

Welcome to Cloudflare’s Impact Week

Adjusting pricing, introducing annual plans, and accelerating innovation

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.

Adjusting pricing, introducing annual plans, and accelerating innovation

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.

Adjusting pricing, introducing annual plans, and accelerating innovation
Slide from the Cloudflare Launch Presentation at TechCrunch Disrupt, September 27, 2010‌‌

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.

Adjusting pricing, introducing annual plans, and accelerating innovation
Cloudflare’s Network as of June 16, 2012, courtesy of The Internet Archive’s Wayback Machine‌‌

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.

Adjusting pricing, introducing annual plans, and accelerating innovation

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.

Adjusting pricing, introducing annual plans, and accelerating innovation

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.

Adjusting pricing, introducing annual plans, and accelerating innovation

Cloudflare’s 2022 Annual Founders’ Letter

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

Cloudflare’s 2022 Annual Founders’ Letter

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.

Cloudflare’s 2022 Annual Founders’ Letter

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.

Cloudflare’s 2022 Annual Founders’ Letter

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.

Cloudflare’s 2022 Annual Founders’ Letter

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.

Cloudflare’s 2022 Annual Founders’ Letter

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.

Cloudflare’s 2022 Annual Founders’ Letter

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.

Cloudflare’s 2022 Annual Founders’ Letter

Blocking Kiwifarms

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.

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

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

Cloudflare's abuse policies & 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.

Cloudflare's abuse policies & approach

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.

Cloudflare's abuse policies & approach

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.

Cloudflare's abuse policies & approach

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

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

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.

Políticas y enfoque de Cloudflare contra el 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.

Políticas y enfoque de Cloudflare contra el abuso

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.

Políticas y enfoque de Cloudflare contra el abuso

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の不正利用に対するポリシーとその取り組み

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

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

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のお客様の大多数はまだ当社のホスティング製品を使用していないため、これらの製品に関する不正利用の苦情や措置は現在のところ比較的まれです。

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

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

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

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

セキュリティサービス

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

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

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

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

権力の濫用を避ける

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

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

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

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

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

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

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

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サービスを停止するタイミングの決定については、一般的な意見ではなく、法的手続きに基づいて判断します。

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

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

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

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

Cloudflare 的滥用处理政策和方法

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

Cloudflare 的滥用处理政策和方法

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

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

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

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

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

安全服务

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

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

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

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

避免滥用权力

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

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

根据所学知识改进政策

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

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

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

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

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% 服务费用捐赠给该组织。无论是现在和将来，我们都不会公开讨论这些努力，因为我们这样做不是为了营销目的，而是因为其符合我们的道德观念。

法治

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

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

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

Cloudflare 的滥用处理政策和方法

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

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

Cloudflare: Richtlinien zu & Umgang mit Regelverstößen

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: 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.

Cloudflare: Richtlinien zu & Umgang mit Regelverstößen

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.

Cloudflare: Richtlinien zu & Umgang mit Regelverstößen

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.

Cloudflare: Richtlinien zu & Umgang mit Regelverstößen

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.

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

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

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.

Politiques et approche de Cloudflare en matière d'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.

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

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.

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

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.

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

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

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:

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

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:

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

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.

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

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!

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/what-cloudflare-is-doing-to-keep-the-open-internet-flowing-into-russia-and-keep-attacks-from-getting-out/

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

Following Russia’s unjustified and tragic invasion of Ukraine in late February, the world has watched closely as Russian troops attempted to advance across Ukraine, only to be resisted and repelled by the Ukrainian people. Similarly, we’ve seen a significant amount of cyber attack activity in the region. We continue to work to protect an increasing number of Ukrainian government, media, financial, and nonprofit websites, and we protected the Ukrainian top level domain (.ua) to help keep Ukraine’s presence on the Internet operational.

At the same time, we’ve closely watched significant and unprecedented activity on the Internet in Russia. The Russian government has taken steps to tighten its control over both the technical components and the content of the Russian Internet. For their part, the people in Russia are doing something very different. They have been adopting tools to maintain access to the global Internet, and they have been seeking out non-Russian media sources. This blog post outlines what we’ve observed.

The Russian Government asserts control over the Internet

Over the last five years, the Russian government has taken steps to tighten its control of a sovereign Internet within Russia’s borders, including laws requiring Russian ISPs to install equipment allowing the government to monitor and block Internet activity, and requiring the establishment of an exclusively Russian DNS (outside ICANN).  And it created mechanisms for the Russian government to control how Russia was connected to the global Internet, so they could pull the plug if they wanted.

Since the Russian invasion of Ukraine, the Russian government has made a series of announcements related to implementation of its sovereign Internet laws. Russian government agencies were instructed to switch to Russian DNS servers, move public resources to Russian hosting services, and take a number of other steps designed to reduce reliance on non-Russian providers. Although some took these initiatives as an announcement that Russia intended to disconnect from the global Internet, so far Russia does not appear to have leveraged the tools it has to disconnect itself entirely from the global Internet.  We continue to see connections processing successfully in Russia through non-Russia infrastructure.

In the meantime, authorities in Russia have implemented a series of targeted blocking actions against websites and operators that they find objectionable. Initially, officials targeted popular social media sites like Facebook, Instagram, Twitter, and YouTube, as well as Russian language outlets based outside of the country.

We can see the effect of some of those blocks on traffic from Russian users to different news websites in Russia and Ukraine before and after blocks were implemented.  

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out
What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out
What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

In each case, these news sites saw exponential growth in their traffic in the days around the February 24th invasion of Ukraine.  But that increase was met within a matter of days by actions to block traffic to those sites. The blocks had varying degrees of success over the first few weeks, though each of them seem to have been eventually successful in denying access to those sources of news through traditional Internet channels.  

But that is only half the story.  As the Russian government took steps to control traditional channels for Internet access, there were shifts in the ways many Russians used the Internet.

Russian citizens turning to tools to gain access to the open Internet

Russians have been adopting applications and tools that allow them to engage with the Internet privately and avoid some of the mechanisms that the Russian government is using to control and monitor access to the Internet. Whereas the most popular applications in the Apple App Store in most of the world in March continue to relate to social media and games, the leaderboard in Russia looked very different:

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

All of the top apps in Russia in March were for private and secure Internet access or encrypted messaging apps, including the most downloaded app – Cloudflare’s own WARP / 1.1.1.1 (a privacy-based recursive DNS resolver). This list of popular apps is a stunning contrast with every other country in the world.

Because of the significant and important popularity of WARP (1.1.1.1), we’ve had some detailed insight into exactly how this has played out. If we look back to the beginning of February we see that Cloudflare’s WARP tool was little used in Russia. Its use took off from the first weekend of the war, and peaked two weeks ago. Later, after this virtual migration to such secure tools became apparent, we saw attempts to block access to the tools used to access the Internet securely.

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

While levels have receded from their peak, a large number of Russians continue to use Cloudflare WARP in Russia at massively higher levels than pre-war.

In addition to the ways Russians are using the Internet increasingly relying on private and encrypted communications, we’ve also seen a shift in what they are trying to access. Here’s a chart of DNS requests from Russian users for a well known US newspaper. Recent DNS traffic for the site has quintupled compared to pre-war levels, indicating Russians are trying to access that news source.

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

And here’s DNS traffic for a large French news source. Again, DNS lookups have grown enormously as Russians try to access it.

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

And here’s a British newspaper.

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

The picture is clear from these three charts. Russians want access to non-Russian news sources and based on the popularity of private Internet access tools and VPNs, they are willing to work to get it.

A front line against cyberattack

In addition to the services we’ve been able to provide average citizens in Russia, our servers at the edge of the Internet in-country have also permitted us to detect and block attacks originating there. When attacks are mitigated inside Russia, they never travel outside Russian borders. That’s always been part of the proposition of Cloudflare’s distributed network – to identify and block cyber attacks (especially DDoS attacks) locally and before they can ever get off the ground.

Here’s what DDoS activity originating inside Russia and blocked there by Cloudflare has looked like since the beginning of February. Normal DDoS activity originating from Russian networks and blocked by Cloudflare’s servers there is relatively low throughout February but then grows massively in the middle of March.

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

To be clear, being able to identify where cyber attack traffic originates is not the same as being able to attribute where the attacker is located. Attributing cyber attacks is difficult, and now is a time to be particularly careful with attribution. It is relatively common for cyber attackers to launch attacks from remote locations around the world. This often happens when they are able to hijack devices in other countries through things like IoT (Internet of Things) corruptions.

But even with such subterfuge, we’ve still seen a significant increase in the number of blocked attacks that are hitting our servers inside Russia.

What Cloudflare is Doing to Keep the Open Internet Flowing into Russia and Keep Attacks from Getting Out

A few weeks ago, as the invasion of Ukraine was in its early stages, I noted that “Russia needs more Internet, not less.” At a time of unprecedented economic sanctions by the United States and Europe, there have been calls for all foreign companies to go further and exit Russia completely, including calls for Internet providers to disconnect Russia. To be clear, Cloudflare has minimal sales and commercial activity in Russia – we’ve never had a corporate entity, an office, or employees there – and we’ve taken steps to ensure that we’re not paying taxes or fees to the Russian government. But given the significant impact of our services on the availability and security of the Internet, we believe removing our services from Russia altogether would do more harm than good.

While we deeply appreciate the motivation of the calls for companies to exit Russia, this withdrawal by Internet companies can have the unintended effect of advancing and entrenching the interests of the Russian government to control the Internet in Russia. Efforts to have Russia cut off from the global Internet through ICANN and RIPE will only cut off the Russian people from information about the war in Ukraine that the Russian government doesn’t want them to access.  After a number of U.S.-based certificate authorities stopped issuing SSL certificates for Russian websites, Russia responded in early March by encouraging Russian citizens to download a Russian Root Certificate Authority instead. As observed by EFF, “the Russian state’s stopgap measure to keep its services running also enables spying on Russians, now and in the future.”

This is why there has been near universal agreement by experts that it is imperative the Russian Internet stay as open as possible for the Russian people. Dozens of civil society groups have urged governments to work to counteract authoritarian actions “and ensure that sanctions and other steps meant to repudiate the Russian government’s illegal actions do not backfire, by reinforcing Putin’s efforts to assert information control.” Russian digital rights activists have pleaded with service providers to offer Russians free VPN access so they are not left isolated from global news sources.  Even the U.S. State Department has made clear, “It is critical to maintain the flow of information to the people of Russia to the fullest extent possible.”

Supporting our mission to help build a better Internet, it’s been a busy six weeks for our team monitoring these developments and working around the clock to make sure Ukrainian web properties are defended and that ordinary Russians can access the global Internet. We remain in awe of the brave Ukrainians standing up in defense of their homeland, and continue to hope that peace will prevail.

Cloudflare, CrowdStrike, and Ping Identity launch the Critical Infrastructure Defense Project

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/announcing-critical-infrastructure-defense/

Cloudflare, CrowdStrike, and Ping Identity launch the Critical Infrastructure Defense Project

Cloudflare, CrowdStrike, and Ping Identity launch the Critical Infrastructure Defense Project

Today, in partnership with CrowdStrike and Ping Identity, Cloudflare is launching the Critical Infrastructure Defense Project (CriticalInfrastructureDefense.org). The Project was born out of conversations with cybersecurity and government experts concerned about potential retaliation to the sanctions that resulted from the Russian invasion of Ukraine.

In particular, there is a fear that critical United States infrastructure will be targeted with cyber attacks. While these attacks may target any industry, the experts we consulted with were particularly concerned about three areas that were often underprepared and could cause significant disruption: hospitals, energy, and water.

To help address that need, Cloudflare, CrowdStrike, and Ping Identity have committed under the Critical Infrastructure Defense Project to offer a broad suite of our products for free for at least the next four months to any United States-based hospital, or energy or water utility. You can learn more at: www.CriticalInfrastructureDefense.org.

We are not powerless against hackers. Organizations that have adopted a Zero Trust approach to security have been successful at mitigating even determined attacks. There are three core components to any Zero Trust security approach: 1) Network Security, 2) Endpoint Security; and 3) Identity.

Cloudflare, CrowdStrike, and Ping Identity launch the Critical Infrastructure Defense Project

Cloudflare, CrowdStrike, and Ping Identity are three of the leading Zero Trust security companies securing each of these components. Cloudflare’s Zero Trust network security offers a broad set of services that organizations can easily implement to ensure their connections are protected no matter where users access the network. CrowdStrike provides a broad set of end point security services to ensure that laptops, phones, and servers are not compromised. And Ping Identity provides identity solutions, including multi-factor authentication, that are foundational to any organization’s posture.

Each of us is great at what we do on our own. Together, we provide an integrated solution that is unrivaled and proven to stand up to even the most sophisticated nation state cyber attacks.

And this is what we think is required, because the current threat is significantly higher than what we have seen since any of our companies was founded. We all built our companies relying on the nation’s infrastructure, and we believe it is incumbent on us to provide our technology in order to protect that infrastructure when it is threatened. For this period of heightened risk, we are all providing our services at no cost to organizations in these most vulnerable sectors.

We’ve also worked together to ensure our products function in harmony and are easy to implement. We don’t want short-staffed IT teams, long requisition processes, or limited budgets to stand in the way of getting the protection that’s needed in place immediately. We’ve taken a cue from hospitals to triage the risks through a recommended list showing organizations that may be short of IT staff how they can proceed: suggesting what they should prioritize over the next day, over the next week, and over the next month.

You can download the recommended security triage program here. We know that not every organization will be able to implement every recommendation. But every step you get through on the list will help your organization be incrementally better prepared for whatever is to come.

Our teams are also committed to working directly with organizations in these sectors to make onboarding as quick and painless as possible. We will onboard customers under this project with the same level of service as if they were our largest paying customers. We believe it is our duty to help ensure that the nation’s critical infrastructure remains online and available through this challenging time.

We anticipate that, based on what we learn over the days ahead, the Critical Infrastructure Defense Project may expand to additional sectors and countries. We hope the predictions of retaliatory cyberattacks don’t come true. But, if they do, we know our solutions can mitigate the risk, and we stand ready to fully deploy them to protect our most critical infrastructure.

Cloudflare, CrowdStrike, and Ping Identity launch the Critical Infrastructure Defense Project

Steps we’ve taken around Cloudflare’s services in Ukraine, Belarus, and Russia

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/steps-taken-around-cloudflares-services-in-ukraine-belarus-and-russia/

Steps we've taken around Cloudflare's services in Ukraine, Belarus, and Russia

At Cloudflare, we’ve watched in horror the Russian invasion of Ukraine. As the possibility of war looked more likely, we began to carefully monitor the situation on the ground, with the goal of keeping our employees, our customers, and our network safe.

Helping protect Ukraine against cyberattacks

Attacks against the Internet in Ukraine began even before the start of the invasion. Those attacks—and the steady stream of DDoS attacks we’ve seen in the days since—prompted us to extend our services to Ukrainian government and telecom organizations at no cost in order to ensure they can continue to operate and deliver critical information to their citizens as well as to the rest of the world about what is happening to them.

Going beyond that, under Project Galileo, we are expediting onboarding of any Ukrainian entities for our full suite of protections. We are currently assisting more than sixty organizations in Ukraine and the region—with about 25% of those organizations coming aboard during the current crisis. Many of the new organizations are groups coming together to assist refugees, share vital information, or members of the Ukrainian diaspora in nearby countries looking to organize and help. Any Ukrainian organizations that are facing attack can apply for free protection under Project Galileo by visiting www.cloudflare.com/galileo, and we will expedite their review and approval.

Securing our customers’ data during the conflict

In order to preserve the integrity of customer data, we moved customer encryption key material out of our data centers in Ukraine, Russia, and Belarus. Our services continued to operate in the regions using our Keyless SSL technology, which allows encryption sessions to be terminated in a secure data center away from where there may be a risk of compromise.

If any of our facilities or servers in Ukraine, Belarus, or Russia lose power or connectivity to the Internet, we have configured them to brick themselves. All data on disk is encrypted with keys that are not stored on site. Bricked machines will not be able to be booted unless a secure, machine-specific key that is not stored on site is entered.

Monitoring Internet availability in Ukraine

Our team continues to monitor Internet patterns across Ukraine. While usage across the country has declined over the last 10 days, we are thankful that in most locations the Internet is still accessible.

Steps we've taken around Cloudflare's services in Ukraine, Belarus, and Russia

We are taking steps to ensure that, as long as there is connectivity out of the country, our services will continue to operate.

Staying ahead of the threat globally

Cyber threats to Ukrainian customers and telecoms is only part of the broader story of potential cyberattacks. Governments around the world have emphasized that organizations must be prepared to respond to disruptive cyber activity. The US Cybersecurity and Infrastructure Security Agency (CISA), for example, has recommended that all organizations—large and small—go “Shields Up” to protect themselves from attack. The UK’s National Cyber Security Centre has encouraged organizations to improve their cyber resilience.

This is where careful monitoring of the attacks in Ukraine is so important. It doesn’t just help our customers in Ukraine — it helps us learn and improve our products so that we can protect all of our customers globally. When wiper malware was identified in Ukraine, for example, we adapted our Zero Trust products to make sure our customers were protected.

We’ve long believed that everyone should have access to cybersecurity tools to protect themselves, regardless of their size or resources. But during this time of heightened threat, access to cybersecurity services is particularly critical. We have a number of free services available to protect you online — and we encourage you to take advantage of them.

Providing services in Russia

Since the invasion, providing any services in Russia is understandably fraught. Governments have been united in imposing a stream of new sanctions and there have even been some calls to disconnect Russia from the global Internet. As discussed by ICANN, the Internet Society, the Electronic Frontier Foundation, and Techdirt, among others, the consequences of such a shutdown would be profound.

The scope of new sanctions issued in the last few weeks have been unprecedented in their reach, frequency, and the number of different governments involved. Governments have issued sweeping new sanctions designed to impose severe costs against those who supported the invasion of Ukraine, including government entities and officials in Russia and Belarus. Sanctions have been imposed against Russia’s top financial institutions, including Russia’s two largest banks, fundamentally altering the ability of Russians to access capital. The entire break away territories of Donetsk and Luhansk, including all of the residents of those regions, are subject to comprehensive sanctions. We’ve seen sanctions on state-owned enterprises, elite Russian families, and the leaders of intelligence-directed disinformation outlets.

These sanctions are intended to make sure that those who supported the invasion are held to account. And Cloudflare has taken action to comply. Over the past several years, Cloudflare has developed a robust and comprehensive sanctions compliance program that allows us to track and take immediate steps to comply with new sanctions regulations as they are implemented. In addition to an internal compliance team and outside counsel, we employ third party tools to flag potential matches or partial ownership by sanctioned parties, and we review reports from third-parties about potential connections. We have also worked with government experts inside and outside of the United States to identify when there is a connection between a sanctioned entity and a Cloudflare account.

Over the past week, our team has ensured that we are complying with these new sanctions as they are announced. We have closed off paid access to our network and systems in the new comprehensively-sanctioned regions. And we have terminated any customers we have identified as tied to sanctions, including those related to Russian financial institutions, Russian influence campaigns, and the Russian-affiliated Donetsk and Luhansk governments. We expect additional sanctions are likely to come from governments as they determine additional steps are appropriate, and we will continue to move quickly to comply with those requirements as they are announced.

Beyond this, we have received several calls to terminate all of Cloudflare’s services inside Russia. We have carefully considered these requests and discussed them with government and civil society experts. Our conclusion, in consultation with those experts, is that Russia needs more Internet access, not less.

As the conflict has continued, we’ve seen a dramatic increase in requests from Russian networks to worldwide media, reflecting a desire by ordinary Russian citizens to see world news beyond that provided within Russia.

Steps we've taken around Cloudflare's services in Ukraine, Belarus, and Russia

We’ve also seen an increase in Russian blocking and throttling efforts, combined with Russian efforts to control the content of the media operating inside Russia with a new “fake news” law.

The Russian government itself, over the last several years, has threatened repeatedly to block certain Cloudflare services and customers. Indiscriminately terminating service would do little to harm the Russian government, but would both limit access to information outside the country, and make significantly more vulnerable those who have used us to shield themselves as they have criticized the government.

In fact, we believe the Russian government would celebrate us shutting down Cloudflare’s services in Russia. We absolutely appreciate the spirit of many Ukrainians making requests across the tech sector for companies to terminate services in Russia. However, when what Cloudflare is fundamentally providing is a more open, private, and secure Internet, we believe that shutting down Cloudflare’s services entirely in Russia would be a mistake.

Our thoughts are with the people of Ukraine and the entire team at Cloudflare prays for a peaceful resolution as soon as possible.

Why Cloudflare Bought Zaraz

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/why-cloudflare-bought-zaraz/

Why Cloudflare Bought Zaraz

Why Cloudflare Bought Zaraz

Today we’re excited to announce that Cloudflare has acquired Zaraz. The Zaraz value proposition aligns with Cloudflare’s mission. They aim to make the web more secure, more reliable, and faster. And they built their solution on Cloudflare Workers. In other words, it was a no-brainer that we invite them to join our team.

Be Careful Who Takes Out the Trash

To understand Zaraz’s value proposition, you need to understand one of the biggest risks to most websites that people aren’t paying enough attention to. And, to understand that, let me use an analogy.

Imagine you run a business. Imagine that business is, I don’t know, a pharmacy. You have employees. They have a process and way they do things. They’re under contract, and you conduct background checks before you hire them. They do their jobs well and you trust them. One day, however, you realize that no one is emptying the trash. So you ask your team to find someone to empty the trash regularly.

Your team is busy and no one has the time to add this to their regular duties. But one plucky employee has an idea. He goes out on the street and hails down a relative stranger. “Hey,” your employee says to the stranger. “I’ve seen you walking by this way every day. Would you mind stopping in and taking out the trash when you do?”

“Uh”, the stranger says. “Sure?!”

“Great,” your employee says. “Here’s a badge that will let you into the building. The trash is behind the secure area of the pharmacy, but, don’t worry, just use the badge, and you can get back there. You look trustworthy. This will work out great!!”

And for a while it does. The stranger swings by every day. Takes out the trash. Behaves exactly as hoped. And no one thinks much about the trash again.

But one day you walk in, and the pharmacy has been robbed. Drugs stolen, patient records missing. Logs indicate that it was the stranger’s badge that had been used to access the pharmacy. You track down the stranger, and he says “Hey, that sucks, but it wasn’t me”. I handed off that trash responsibility to someone else long ago when I stopped walking past the pharmacy every day.”

And you never track down the person who used the privileged access to violate your trust.

The Keys to the Kingdom

Now, of course, this is crazy. No one would go pick a random stranger off the street and give them access to their physical store. And yet, in the virtual world, a version of this happens all the time.

Every day, front end developers, marketers, and even security teams embed third-party scripts directly on their web pages. These scripts perform basic tasks — the metaphorical equivalent of taking out the trash. When performing correctly, they can be valuable at bringing advanced functionality to sites, helping track marketing conversions, providing analytics, or stopping fraud. But, if they ever go bad, they can cause significant problems and even steal data.

At the most mundane, poorly configured scripts can slow down the rendering pages. While there are ways to make scripts non-blocking, the unfortunate reality is that their developers don’t always follow the best practices. Often when we see slow websites, the biggest cause of slowness is all the third-party scripts that have been embedded.

But it can be worse. Much worse. At Cloudflare, we’ve seen this first hand. Back in 2019 a hacker compromised a third-party service that Cloudflare used and modified the third-party JavaScript that was loaded into a page on cloudflare.com. Their aim was to steal login cookies, usernames and passwords. They went so far as to automatically create username and password fields that would autocomplete.

Here’s a snippet of the actual code injected:

        var cf_form = document.createElement("form");
        cf_form.style.display = "none";
        document.body.appendChild(cf_form);
        var cf_email = document.createElement("input");
        cf_email.setAttribute("type", "text");
        cf_email.setAttribute("name", "email");
        cf_email.setAttribute("autocomplete", "username");
        cf_email.setAttribute("id", "_email_");
        cf_email.style.display = "none";
        cf_form.appendChild(cf_email);
        var cf_password = document.createElement("input");
        cf_password.setAttribute("type", "password");
        cf_password.setAttribute("name", "password");
        cf_password.setAttribute("autocomplete", "current-password");
        cf_password.setAttribute("id", "_password_");
        cf_password.style.display = "none";
        cf_form.appendChild(cf_password);

Luckily, this attack caused minimal damage because it was caught very quickly by the team, but it highlights the very real danger of third-party JavaScript. Why should code designed to count clicks even be allowed to create a password field?

Put simply, third-party JavaScript is a security nightmare for the web. What looks like a simple one-line change (“just add this JavaScript to get free page view tracking!”) opens a door to malicious code that you simply don’t control.

And worse is that third-party JavaScript can and does load other JavaScript from other unknown parties. Even if you trust the company whose code you’ve chosen to embed, you probably don’t trust (or even know about!) what they choose to include.

And even worse these scripts can change any time. Security threats can come and go. The attacker who went after Cloudflare compromised the third-party and modified their service to only attack Cloudflare and included anti-debugging features to try to stop developers spotting the hack. If you’re a CIO and this doesn’t freak you out already, ask your web development team how many third-party scripts are on your websites. Do you trust them all?

The practice of adding third-party scripts to handle simple tasks is the literal equivalent of pulling a random stranger off the street, giving them physical access to your office, and asking them to stop by once a day to empty the trash. It’s completely crazy in the physical world, and yet it’s common practice in web development.

Sandboxing the Strangers

At Cloudflare, our solution was draconian. We ordered that all third-party scripts be stripped from our websites. Different teams at Cloudflare were concerned. Especially our marketing team, who used these scripts to assess whether the campaigns they were running were successful. But we made the decision that it was more important to protect the integrity of our service than to have visibility into things like marketing campaigns.

It was around this time that we met the team behind Zaraz. They argued there didn’t need to be such a drastic choice. What if, instead, you could strictly control what the scripts that you insert on your page did. Make sure if ever they were compromised they wouldn’t have access to anything they weren’t authorized to see. Ensure that if they failed or were slow they wouldn’t keep a page from rendering.

We’ve spent the last half year testing Zaraz, and it’s magical. It gives you the best of the flexible, extensible web while ensuring that CIOs and CISOs can sleep well at night knowing that even if a third-party script provider is compromised, it won’t result in a security incident.

To put a fine point on it, had Cloudflare been running Zaraz then the threat from the compromised script we saw in 2019 would have been completely and automatically eliminated. There’s no way for the attacker to create those username and password fields, no access to cookies that are stored in the user’s browser. The attack surface would have been completely removed.

We’ve published two other posts today outlining how Zaraz works as well as examples of how companies are using it to ensure their web presence is secure, reliable, and fast. We are making Zaraz available to our Enterprise customers immediately, and all other customers can access a free beta version on their dashboard starting today.

If you’re a third-party script developer, be on notice that if you’re not properly securing your scripts, then as Zaraz rolls out across more of the web your scripts will stop working. Today, Cloudflare sits in front of nearly 20% of all websites and, before long, we expect Zaraz’s technology will help protect all of them. We want to make sure all scripts running on our customers’ sites meet modern security, reliability, and performance standards. If you need help getting there, please reach out, and we’ll be standing ready to help: [email protected].

In the meantime, we encourage you to read about how the Zaraz technology works and how customers like Instacart are using it to build a better web presence.

It’s terrific to have Zaraz on board, furthering Cloudflare’s mission to help build a better Internet. Welcome to the team. And in that vein: we’d like to welcome you to Zaraz! We’re excited for you to get your hands on this piece of technology that makes the web better.

Cloudflare’s Annual Founders’ Letter

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

Cloudflare’s Annual Founders’ Letter

Cloudflare’s Annual Founders’ Letter

This week we celebrate Cloudflare’s birthday. We launched the company 11 years ago tomorrow: September 27, 2010. It has been our tradition, since our first birthday, to use this week to launch innovative new products that we think of as our gift back to the Internet.

Since going public, it’s also been an opportunity for us to update our Annual Founders’ Letter and share what’s on our mind. Recently we’ve been thinking about three things: team, the Internet, and innovation.

Team

When anyone asks us the key to Cloudflare’s success, we always say the same thing: the team we’ve been able to attract to help us achieve our mission of helping build a better Internet. In the last year we’ve had more than 250,000 people apply to work for us and extended offers to less than one half of one percent of them. We continue to attract great people.

It’s incredible to realize that more than half of Cloudflare’s team today started since March 13, 2020, when we closed all our physical offices due to the pandemic. In the last several months, as we’ve started to see a light at the end of the COVID tunnel, we’ve been hosting what we called Summer Socials with our team. Getting together outside, often over a picnic lunch, it’s been fun to meet face-to-face people we’d only video conferenced with before. And even more fun to watch people from across the team get to know each other outside the confines of a Brady Bunch-like on-screen box.

Cloudflare’s Annual Founders’ Letter

As a company that was very much a work-from-office culture before the pandemic, we were terrified of what would happen to our culture when we switched to fully remote work. Eighteen months into this forced experiment on a new way of working we’re happy to report: it’s working. Really well.

It turns out what we all suspected is in fact true. Culture has little to do with fun offices, plentiful snacks, or adjustable desks. Instead, for us, it starts with hiring people who are relentlessly curious and, at the same time, empathetic. Curious people want to learn. Empathetic people love to teach. And if you put a group of them together, whether in a swanky office or on Zoom, great things will happen.

As we come out the other side of COVID, we have an opportunity to help build a better way to work. It would be naive to insist that we go back to the way we did things before. We’ve been more productive, and on average our team has been happier in their jobs, than any time in the company’s history. At the same time, we know there can be considerable value in coming together in person to solve hard problems, brainstorm about the future, and build relationships that make the company stronger.

We don’t have all the answers on what the future of work looks like, but we’ve begun to formulate a place to start our experiments as people come back. We hope we can use the times we get together as ways to better collaborate and learn. But, at the same time, give our team the flexibility to work how and wherever they are the most productive.

The Internet

Cloudflare’s mission is to help build a better Internet. We always capitalize the I in Internet, in spite of what the AP style guide has said since 2016, because it’s a proper noun, we believe there is and only should be one, and we have an enduring respect for what a miracle it is that it exists.

Right around the same time that the AP started to say that you needn’t capitalize the I in Internet anymore, something seemed to change. The world shifted from seeing the Internet and what it enabled as an irreproachable good to a source of great danger.

We’ve watched the same thing. Since 2016 it’s often felt like a connection to the Internet only brings cyberattacks, toxic social media, threats to democracy, increasing polarization, and a declining disdainful discourse.

We have real challenges ahead as some of the technologies that ride on top of the Internet have broken down traditional gatekeepers without sufficient concern for addressing the harms they previously protected against. But, at the same time, the Internet itself remains a miracle.

A mere 11 years before Cloudflare’s founding, long distance phone calls still cost a fortune, sharing a photograph with someone in another country took weeks, and the idea that you could access the sum total of human knowledge from a device in your pocket was beyond even the fantasies of science fiction.

Cloudflare’s Annual Founders’ Letter

The last 18 months of the pandemic have reaffirmed our faith in the miracle that is the Internet. Imagine just how much worse it would have been had the pandemic happened just 11 years ago, let alone 22. The Internet allowed many of us to continue to work, connect with our loved ones, exercise our creativity, and stay connected to the world.

We’re proud of what we’ve done to live up to our mission and help build a better Internet during this time. And, as we come out the other side, we will continue to engage with policy makers to address the new harms an interconnected world has brought while preserving the miracle that is the Internet itself.

Innovation

The Internet may seem static, but it is not. 11 years ago, watching a video online was an exercise in frustration. Today, it seems almost automatic that you can push play on your TV and access nearly any movie ever made instantly. That’s possible because the Internet isn’t static; it gets better through innovation.

Cloudflare’s Annual Founders’ Letter

At Cloudflare, we’re optimized to catalyze exactly that innovation. It starts with our mission: to help build a better Internet. The word “help” is important, because we know we can’t do it alone. So, wherever we can, we work with others across the Internet ecosystem to push it forward and make it better.

Sometimes people outside the company are surprised by the products we build. In fact, predicting our roadmap is pretty easy. We look at all the steps that are required to load a web page, send an email, stream a video, login to a workstation, or anything else you do online and ask: can we make that more secure, more reliable, or faster?

What’s exciting is that the pace at which the Internet is getting better is accelerating. And, in turn, the pace at which we are able to launch innovative new products is accelerating along with it. As the Internet grows and acquires more capabilities, we believe we will continue to grow with it. An investment in Cloudflare is, fundamentally, we feel an investment in the Internet itself.

Cloudflare’s Annual Founders’ Letter

And so, this week, we have an incredible series of announcements that are designed to help build a better Internet. We’re entering a new area to close one of the last network security risks that we haven’t historically protected our customers from, driving down costs of core cloud services, pushing the boundary of our network to our customers’ doorsteps, and investing in new technologies that may someday disrupt the web as we know it today.

Thank you to our team, our customers, and our investors. Happy 11th birthday to Cloudflare. And, even as we pick up steam, we continue to believe: we’re just getting started.

Cloudflare’s Annual Founders’ Letter

From AMP to Signed Exchanges, Or How Innovation Happens at Cloudflare

Post Syndicated from Matthew Prince original https://blog.cloudflare.com/from-amp-to-signed-exchanges-or-how-innovation-happens-at-cloudflare/

From AMP to Signed Exchanges, Or How Innovation Happens at Cloudflare

From AMP to Signed Exchanges, Or How Innovation Happens at Cloudflare

This is the story of how we decided to work with Google to build Signed Exchanges support at Cloudflare. But, more generally, it’s also a story of how Cloudflare thinks about building disruptive new products and how we’ve built an organization designed around continuous innovation and long-term thinking.

A Threat to the Open Web?

The story starts with me pretty freaked out. In May 2015, Facebook had announced a new format for the web called Instant Articles. The format allowed publishers to package up their pages and serve them directly from Facebook’s infrastructure. This was a threat to Google, so the company responded in October with Accelerated Mobile Pages (AMP). The idea was generally the same as Facebook’s but using Google’s infrastructure.

As a general Internet user, if these initiatives were successful they were pretty scary. The end game was that the entirety of the web would effectively be slurped into Facebook and Google’s infrastructure.

But as the cofounder and CEO of Cloudflare, this presented an even more immediate risk. If everyone moved their infrastructure to Facebook and Google, there wasn’t much left for us to do. Our mission is to help build a better Internet, but we’ve always assumed there would be an Internet. If Facebook and Google were successful, there was real risk there would just be Facebook and Google.

That said, the rationale behind these initiatives was compelling. While they ended with giving Facebook and Google much more control, they started by trying to solve a real problem. The web was designed with the assumption that the devices connecting to it would be on a fixed, wired connection. As more of the web moved to being accessed over wireless, battery-powered, relatively low-power devices, many of the assumptions of the web were holding back its performance.

This is particularly true in the developing world. While a failed connection can happen anywhere, the further you get from where content is hosted, the more likely it is to happen. Facebook and Google both reasoned that if they could package up the web and serve complete copies of pages from their infrastructure, which spanned the developing world, they could significantly increase the usability of the web in areas where there was still an opportunity for Internet usage to grow. Again, this is a laudable goal. But, if successful, the results would have been dreadful for the Internet as we know it.

Seeds of Disruption

So that’s why I was freaked out. In our management meetings at Cloudflare I’d walk through how this was a risk to the Internet and our business, and we needed to come up with a strategy to address it. Everyone on our team listened and agreed but ultimately and reasonably said: that’s in the future, and we have immediate priorities of things our customers need, so we’ll need to wait until next quarter to prioritize it.

That’s all correct, and probably the right decision if you are forced to make one, but it’s also how companies end up getting disrupted. So, in 2016, we decided to fund a small team led by Dane Knecht, Cloudflare’s founding product manager, to set up a sort of skunkworks team in Austin, TX. The idea was to give the team space away from headquarters, so it could work on strategic projects with a long payoff time horizon.

Today, Dane’s team is known as the Emerging Technologies & Incubation (ETI) team. It was where products like Cloudflare for Teams, 1.1.1.1, and Workers were first dreamed up and prototyped. And it remains critical to how Cloudflare continues to be so innovative. Austin, since 2016, has also grown from a small skunkworks outpost to what will, before the end of this year, be our largest office. That office now houses members from every Cloudflare team, not just ETI. But, in some ways, it all started with trying to figure out how we should respond to Instant Articles and AMP.

We met with both Facebook and Google. Facebook’s view of the world was entirely centered around their app, and didn’t leave much room for partners. Google, on the other hand, was born out of the open web and still ultimately wanted to foster it. While there has been a lot of criticism of AMP, much of which we discussed with them directly, it’s important to acknowledge that it started from a noble goal: to make the web faster and easier to use for those with limited Internet resources.

We built a number of products to extend the AMP ecosystem and make it more open. Viewed on their own, those products have not been successes. But they catalyzed a number of other innovations. For instance, building a third party AMP cache on Cloudflare required a more programmable network. That directly resulted in us prototyping a number of different serverless computing strategies and finally settling on Workers. In fact, many of the AMP products we built were the first products built using Workers.

Part of the magic of our ETI team is that they are constantly trying new things. They’re set up differently, in order to take lots of “shots on goal.” Some won’t work, in which case we want them to fail fast. And, even for those that don’t, we are always learning, collaborating, and innovating. That’s how you create a culture of innovation that produces products at the rate we do at Cloudflare.

Signed Exchanges: Helping Build a Better Internet

Importantly also, working with the AMP team at Google helped us better collaborate on ideas around Internet performance. Cloudflare’s mission is to “help build a better Internet.” It’s not to “build a better Internet.” The word “help” is essential and something I’ll always correct if I hear someone leave it out. The Internet is inherently a collection of networks, and also a collection of work from a number of people and organizations. Innovation doesn’t happen in a vacuum but is catalyzed by collaboration and open standards. Working with other great companies who are aligned with democratizing performance optimization technology and speeding up the Internet is how we believe we can make significant and meaningful leaps in terms of performance.

From AMP to Signed Exchanges, Or How Innovation Happens at Cloudflare

And that’s what Signed Exchanges have the opportunity to be. They take the best parts of AMP — in terms of allowing pages to be preloaded to render almost instantly — but give back control over the content to the individual publishers. They don’t require you to exclusively use Google’s infrastructure and are extensible well beyond just traffic originating from search results. And they make the web incredibly fast and more accessible even in those areas where Internet access is slow or expensive.

We’re proud of the part we played in bringing this new technology to the Internet. We’re excited to see how people use it to build faster services available more broadly. And the ETI team is back at work looking over the innovation horizon and continuously asking the question: what’s next?

From AMP to Signed Exchanges, Or How Innovation Happens at Cloudflare