Wikipedia provides the most succinct description of an NSL:

An NSL is an administrative subpoena issued by the United States federal government to gather information for national security purposes. NSLs do not require prior approval from a judge.… NSLs typically contain a nondisclosure requirement, frequently called a "gag order", preventing the recipient of an NSL from disclosing that the FBI had requested the information. https://en.wikipedia.org/wiki/National_security_letter

Shortly before the New Year, the FBI sent us the following letter about that NSL.

The letter withdrew the nondisclosure provisions (the “gag order”) contained in NSL-12-358696, which had constrained Cloudflare since the NSL was served in February 2013. At that time, Cloudflare objected to the NSL. The Electronic Frontier Foundation agreed to take our case, and with their assistance, we brought a lawsuit under seal to protect its customers' rights.

Early in the litigation, the FBI rescinded the NSL in July 2013 and withdrew the request for information. So no customer information was ever disclosed by Cloudflare pursuant to this NSL.

Even though the request for information was no longer at issue, the NSL’s gag order remained. For nearly four years, Cloudflare has pursued its legal rights to be transparent about this request despite the threat of criminal liability. As explained above, the FBI recently removed that gag order, so we are now able to share the redacted text of NSL-12-358696, which reads as follows:

Consistent with the FBI’s request and Cloudflare policy, we have voluntarily redacted personal information about the FBI Special Agent named in the NSL as well as customer account information. Disclosing this information would provide no public benefit.

The gag order not only impacted our transparency report and our ability to talk about the sealed case, but Cloudflare has been involved in public policy discussions related to the Internet and matters of electronic communications both in Congress and in the public sphere more broadly since the early days of the company. We believe that participation in policy debates is an axiomatic part of our mission to build a better internet. The inability to disclose the receipt of NSLs and to participate in a robust discussion of the policy issues surrounding NSLs was important to Cloudflare and the members of our community.

One personal experience is particularly telling about the gag order’s negative impact on our policy advocacy efforts. In early 2014, I met with a key Capitol Hill staffer who worked on issues related to counter-terrorism, homeland security, and the judiciary. I had a conversation where I explained how Cloudflare values transparency, due process of law, and expressed concerns that NSLs are unconstitutional tools of convenience rather than necessity. The staffer dismissed my concerns and expressed that Cloudflare’s position on NSLs was a product of needless worrying, speculation, and misinformation. The staffer noted it would be impossible for an NSL to issue against Cloudflare, since the services our company provides expressly did not fall within the jurisdiction of the NSL statute. The staffer went so far as to open a copy of the U.S. Code and read from the statutory language to make her point.

Because of the gag order, I had to sit in silence, implicitly confirming the point in the mind of the staffer. At the time, I knew for a certainty that the FBI’s interpretation of the statute diverged from hers (and presumably that of her boss).

Cloudflare fought this battle for four years even after the request for customer information had been dismissed. In addition to protecting our customers’ information, we want to remain a vigorous participation in public policy discussions about our services and public law enforcement efforts. The gag rule did not allow that.

Now that this gag order has been lifted, Cloudflare is able to publish a more accurate transparency report to its customers and constituents. For us, this is not the end of the story, but the beginning of a more robust, fact-informed debate.

Earlier today, the lower house in the U.S. Congress (the House of Representatives) passed the USA FREEDOM Act. The Act, if passed by the Senate and signed by the President, would seek to sunset the National Security Agency’s bulk collection and mass surveillance programs, which may or may not be authorized by Section 215 of the PATRIOT Act. Under this authority the U.S. government has established its broad surveillance programs to indiscriminately collect information. Other governments have followed this lead to create additional surveillance capabilities—most recently, the French Parliament has moved a bill that would allow broad surveillance powers with little judicial oversight.

Restricting routine bulk collection is important: it’s not the government’s job to collect everything that passes over the Internet. The new version of the USA FREEDOM Act keeps useful authorities but ends bulk collection of private data under the PATRIOT Act. It also increases the transparency of the secret FISA court, which reviews surveillance programs—a key start to understanding and fixing broken policies around surveillance. The Act would also allow companies to be more transparent in their reporting related to FISA orders.

To be clear, we continue to be supportive of law enforcement and work productively with them on their investigations, under the due process of law. However, numerous assessments in the U.S. and elsewhere have shown that bulk collection programs are ineffectual.

CloudFlare wholeheartedly supports the USA FREEDOM Act’s passage and adoption as law. We believe that the NSA’s mass surveillance programs are illegal and unconstitutional. CloudFlare has a long track record of opposing these programs since they deprive Internet users the due process of law that the Constitution requires. We recently joined with the Center for Democracy and Technology, the Open Technology Institute, Access, and other leading tech policy organizations and tech companies to support the Act’s passage. The passage of the USA FREEDOM Acts is just one step towards ensuring national security under the rule of law. There is more work to be done to ensure that the agencies charged with keeping us safe do so responsibly, in order to maintain trust in the web.

In the meanwhile, we urge the Senate and President Obama to complete the work of the House and pass the USA FREEDOM Act into law.

What’s in a Name?

Earlier today, CloudFlare announced Project Galileo to protect free speech on the Web by using its sophisticated anti-DDoS resources. Seventeen (at last count) free speech, public interest, and civil society organizations are helping us identify at-risk, in-need websites for the Project. If one these websites comes under attack, CloudFlare will make sure that the website stays online.

You can read more about the story in the press in: ArsTechnica; Re/Code; Slate; TechCrunch; and The Verge.

Since we’ve launched, we keep getting asked why we called it “Project Galileo.”

In 1610, Galileo Galilei fashioned a homemade telescope and pointed it towards the heavens. He saw sights never witnessed before by human eyes: moons orbiting Jupiter, rings around Saturn, sunspots, craters on the moon, and phases of Venus.

These observations gave evidence for a dangerous truth—we are not the center of the universe, and the Earth revolves around the sun. Galileo published his discoveries in a book modestly entitled Dialogue Concerning the Two Chief World Systems. As reward for his discoveries, Galileo was labeled a heretic and his book was banned until 1718. The Earth was to revolve around the sun 107 more times before Galileo’s discoveries would reach a wider audience.

Like Galileo, websites espousing politically sensitive—even heretical—speech are often victims of suppression. Like Galileo, most of these sites don’t have the resources to protect their discoveries from being suppressed.

How would history be different if Galileo’s book had been able to stay “online”? Would we have reached the moon in July 1861, not 1969?

If you would like to help Project Galileo as a public interest organization, identifying those websites most in need, please visit: www.projectgalileo.org. If you would like to be a participating website, we suggest you contact one of our partner organizations so they can recommend you.

Today, CloudFlare is publishing its first complete Transparency Report on governmental requests to coincide with TrustyCon.

The Transparency Report shows how many subpoenas, court orders, search warrants, pen register/trap and trace (PRTT) orders, and national security orders CloudFlare received and how many domains and accounts were affected by CloudFlare’s response those requests in 2013. The report does not include non-governmental requests.

All totaled, the requests received affected fewer than 0.017% of the more than 2 million CloudFlare customers domains.

CloudFlare operates a global network and is extremely mindful of the responsibility that comes with that privileged position. It is CloudFlare’s overriding privacy principle to protect and secure our customers’ information; we will not sell, rent, or give away any of their personal information without their consent. An essential part of protecting our customers’ right to privacy and to earning their trust is being transparent about the governmental requests we receive.

We will continue to update this report on a semiannual basis at Transparency Report.

Earlier today, the Department of Justice and the Director of National Intelligence announced a change in rules governing the disclosure of National Security Orders, including National Security Letters (NSLs) received by a company. The DoJ and DNI now allow companies to disclose the number of NSLs and FISA orders as a single number in bands of 250, starting with 0-249.

For us at CloudFlare, we have long felt that the arguments in support of restricting the disclosure of NSLs to be flawed. We see no threat to national security by acknowledging the program or the number of orders a particular company has received. Further, it is frustrating that most assume the program to be widespread and that tech companies receive NSLs on a daily basis. In fact, Apple is reporting today that it has received between 0-249 National Security Orders. If a company of Apple’s size has received fewer than 250 National Security Orders, the average tech company is most likely receiving a significantly lower amount.

Given the new rules and guidelines, CloudFlare is publishing its initial Transparency Report on National Security Orders. (We will publish a more complete Transparency Report later on this year). CloudFlare has received the following:

In terms of impact on our customers, even assuming the high end of the range, these National Security Orders would affect fewer than 0.02% of CloudFlare customers.

We believe that while it does not go far enough, today’s rule change is a step in the right direction. Moreover, we believe NSLs violate the principles of Due Process. CloudFlare will therefore challenge in court any NSLs we receive. If this means appealing all the way to the US Supreme Court, then so be it.

We believe that markets where large companies set the terms and small companies or new entrants are excluded to be inherently flawed. This would throw us back to the times of the Bell System, when it took decades of legal battles to launch innovative products such as the Hush-a-Phone or the Carterfone. There are two ways to guard against such an outcome. The first is to enact a mother-may-I set of rules which would strictly forbid certain types of network practices and where ISPs would have to get permission first. The second requires adjudicating instances of unreasonable discrimination on a case-by-case basis. No one knows just what is beyond the pale in advance, since it is on a case-by-case basis.

First, let’s take a brief look at the FCC, network neutrality, and the court ruling. The FCC is an independent U.S. agency charged with delegated rule-making authority from Congress to regulate “all interstate and foreign communications by wire or radio.” 47 U.S.C. § 152(a). The FCC regulates telephone carriers, cable companies, television stations, wireless providers, and satellite companies. Network neutrality is a catch-all phrase that emerged in the United States over the past decade. It is intended to ensure that network providers’ traffic practices treat all IP packets more or less the same in order to preserve the open characteristics of the Internet.

Back in 2010, the FCC established network neutrality rules which prevented broadband access providers from unreasonably discriminating against non-affiliated content or blocking any content, and required them to disclose their network traffic treatment practices to their end users. Verizon, a large access provider, brought a suit challenging the rules.

In the long-awaited decision the DC Circuit Court released this week, the court struck down the FCC's anti-discrimination and anti blocking rules, but upheld the FCC requirements that broadband providers disclose their network practices. The court reached this conclusion, not based on the policy of network neutrality, which it found to be ustified. Instead, it reversed the FCC’s 2010 rules based on the way the FCC had tried to shoehorn broadband access into the FCC jurisdiction over certain carriers. The FCC chose not to treat broadband providers under the rules it uses to govern phone companies (its traditional home turf), but under its general authority to regulate communications.

The implications of the court’s ruling is that it will either spur innovation or stifle it, depending on whom you ask. One side of the debate argues that broadband Internet providers are now free to experiment with new network arrangements and business models without getting permission from the FCC. The other side argues that there are real risks which, if left unchecked, could undermine new entrants and the freedom to innovate without permission from the ISPs.

Most broadband providers have already adopted some form of network neutrality practice, so the immediate short-run implications of the ruling are likely to be small. However, the ruling’s long-term implications could stifle innovation. A broadband access provider is now completely free to treat traffic in almost any way it chooses. It can block certain websites, provide priority access, charge edge providers, or throttle applications, so long as it discloses that treatment to its subscribers. Defenders of net neutrality fear that, in the long run, voluntary rules are likely to go the way of the PC as broadband providers seek increased control over their networks. There is the very real possibility that this rule change will give broadband providers more control over the content and applications their customers can download.

For the big companies like Verizon, Comcast, AT&T, Google, Amazon, and Netflix this is not a really big deal. They have armies of lawyers to settle the issue (I know, I used to be one). At the end of the day, they may reach some sort of accord where Google, Amazon, and Netflix pull up the ladder behind them, preventing new services from coming along.

The smaller players, thanks to this ruling, might in the future, face bandwidth that is more expensive, peering that is harder to get, and access to end users that is more difficult thanks to degradation of their traffic. This outcome would make innovation more difficult, not for the Amazons and Googles of the world, but for the more than 45,000 small hosting providers, the Dropboxes, the Imgurs, and the next generation of start-ups currently trying to take hold.

The entrepreneurs with just an idea and a slide deck may find themselves completely marginalized. If access to the Internet becomes sufficiently expensive and limited, then new entrants may find all venture capital dried up. USV partner Fred Wilson explains this possible outcome succinctly.

The DC Circuit Court expressly gave the FCC such an ad hoc way forward. CloudFlare can help in this approach. One of the reasons the FCC (and indeed regulators around the world) were unwilling to impose strong network neutrality rules was the absence of strong evidence of the potential harms. This might have been a chicken-and-egg problem. FCC jawboning, the spectre of regulation, and certain merger commitments may have been sufficient to keep broadband providers honest. So, if the bad outcomes I have described start to emerge, we need to document them and make that record.

For a small start-up, CloudFlare occupies a special position at the edge of the network in both the literal and figurative senses. Our co-founder Michelle Zatlyn serves on the FCC’s Open Internet Advisory Committee. She is the only representative from a start-up on the Committee. One of our investors, Brad Burnham, is also on the Committee. I have completed work on network neutrality issues over the course of most of the past decade including, an international comparison of approaches; a study for the European Parliament; one for the German government’s FCC; and one for the ITU Association of Japan. We are also plugged in to the developer community, the VC community, the public interest community, and the FCC. To the extent that our customers and colleagues have experienced the worst case fears of network neutrality, we want to know.

The future of a free and open Internet requires those developing the next generation of innovation to be better informed and more involved in the policy process. It also requires that policymakers know what is happening in the real world. CloudFlare will watch the developments carefully and track what happens. We can surface genuine problems more than mere hypotheticals. CloudFlare can then advocate on behalf of startups and the non-giants to preserve the principles of a free and open Internet.

In full disclosure, the author was formerly an attorney for both the FCC and for Google, where he worked on these issues. He is unrelated to Thomas Carter, the inventor of the Carterfone.

Over the weekend, I happened by a pumpkin carving contest in Monterey. One of the winning pumpkins was a low-relief scene of a pirate ship. The hull was created by carving the pumpkin in the traditional way. To make the sails, some of the pumpkin skin was cut away giving them a translucent effect. Looking at this, I thought to myself, “Hey, that would be really cool do with the CloudFlare logo.” So I did.

As CloudFlare’s legal counsel, I spend a good deal of my time protecting the trademarks. Since our launch in 2010, the CloudFlare brand has come to stand for something more than just our products and services. The CloudFlare brand is an important symbol of our company’s efforts to build a better Internet. That mission is why I decided to carve my jack-o’-lantern with the CloudFlare logo.

CloudFlare has protected many websites from threats and specters. A quick glance at some of our customers reveals that we have protected 215 websites with the word Halloween from spooky, spooky vampires, trolls, and other demons. We’ve also had 49 ‘scary’ websites, 15 goblins, 10 ghouls, 577 ghosts, 18 spooky, 49 scary, 25 haunted, and 2 trick or treat, but no jack-o’-lanterns.

If you’re the kind of person who can take pride in not just warding off bad spirits but also addressing the serious challenges of building a better Internet, join our team. CloudFlare is hiring.

Wishing you a safe and happy halloween!

To that end, one of the first things I have undertaken in my new role is a full review of our privacy policy. I wanted to strengthen it to make sure that the policy is keeping pace with our growing business and the privacy expectations of our users worldwide. So, I am pleased to announce our new privacy policy effective today.

So what is changing in the new policy? Actually, not all that much. The old privacy policy was pretty good to start. Most of the changes were to more clearly explain how we treat specific information, remove ambiguity, and ensure we are complying with privacy standards around the world. Specifically, here are some of the changes we made:

• We also removed a whole bunch of pronouns and replaced them with nouns. This makes the policy read a good bit more legal and formalistic, but greatly clarifies exactly whom and what we are referring to.

• We have also changed our privacy policy to appoint TRUSTe for dispute resolution relating to our compliance with the U.S.–EU Safe Harbor framework and the U.S.–Swiss Safe Harbor. This ensures we are in line with EU privacy standards. TRUSTe has reviewed our privacy policy and signed off that it meets these Safe Harbor Privacy Principles for protecting users’ privacy.

• We created a new, dedicated Trust and Safety email contact for handling your questions and concerns related to privacy and compliance issues. The address is privacy@cloudflare.com.

• Since it is CloudFlare’s existing corporate policy to ensure adherence to due process in all law enforcement requests for our customers’ information, we decided to explicitly incorporate that policy into our privacy policy. By way of background, here’s our CEO’s a recent interview on the subject of law enforcement and privacy.

To ensure you can understand every change to the privacy policy, I have tracked changes from the old to the new privacy policy and embedded a PDF showing the differences below. I’ve also included comments explaining the rationale of every change. We wanted to show you exactly all the moving pieces, how we’ve sought to improve and clarify our policy, and the reasoning behind every change. Finally, for the more technically (and less legally) inclined, we’ve also included our privacy policy in a public GitHub repo where we will track changes to it over time.

Our guiding philosophy has always been and will continue to be that the personal information you provide to us is just that: personal and private. CloudFlare will not sell, rent, or give away any of your personal information without your consent. We will also challenge law enforcement requests that we determine do not meet the standards of due process.

I will continue to return to this blog to keep you informed as we review and strengthen our policies and procedures going forward.

CloudFlare Security and Privacy Policy August 2013 Difffromcloudflare_policies