slight paranoia

Learning how policy is made in the legislative branch

noreply@blogger.com (Christopher Soghoian) — Thu, 08 Dec 2016 16:04:00 +0000

During my seven years in Washington D.C., I’ve worked for the nation’s premier privacy regulator—the Federal Trade Commission—and for one of the top civil liberties organizations in the United States—the American Civil Liberties Union. These have both been great experiences, but I now want to learn first-hand how policy is made in the legislative branch.

After more than four years at the ACLU, I’ll be leaving the organization on January 6, 2017 to join the new class of TechCongress Congressional Innovation Fellows.

TechCongress is a nonpartisan program incubated New America’s Open Technology Institute that’s dedicated to building 21st century government and developing cross-sector technology leaders. The Congressional Innovation Fellowship was launched in 2015 and places technologists to serve in Congress through a one-year residency on Capitol Hill to gain in-depth understanding of the legislative process. This year’s class includes four fellows with experience across the tech sector.

The specifics of my placement (that is, which Congressional office or Committee I’ll work for) won’t be settled until January.

This fellowship will mean that my life will change in many ways. I’m going to be putting my Twitter account on hold for the duration of my fellowship. Likewise, I won’t I give any public talks or speak to journalists (on or off the record) during that time. Starting in January, I’m going to keep my head down, focus on the job, and try to make the most of this fantastic opportunity. I’ll also be wearing a suit far more often.

I’ve loved my time at the ACLU, I’ve been lucky enough to work with some of the most skilled civil liberties lawyers in the country, on some of the most interesting and exciting technology and surveillance related issues of our time. My team will be hiring someone soon to replace me, so if you have a background in technology, an interest in civil liberties, and an ability to explain things and communicate with empathy to lawyers, journalists and policymakers, please apply once the job is posted.

Goodbye Caspar

noreply@blogger.com (Christopher Soghoian) — Thu, 09 Jul 2015 19:21:00 +0000

I think I first met Caspar Bowden back in 2007.

I first encountered him at privacy conferences, where he would, without fail, be the first person to the microphone anytime a tech company employee or government official spoke, and he would hammer them with the most uncomfortable, probing questions about privacy and surveillance.

The thing is, there are very few new faces on the privacy circuit. Many of these people had encountered Caspar before and had been on the receiving end of his unpleasant questions. If they gave a bullshit answer, the next time he asked the question, he would come prepared with material to respond. If they evaded, the next time he asked the question, he would mention how many times they had evaded it. He was relentless. It worked. He would ask the same questions over and over, until he finally browbreat them into giving an honest answer, on the record, in front of a room full of privacy experts, officials, and academics.

As a young, green activist, I was in awe.

Moreover, Caspar had somehow convinced Microsoft to hire him, to pay him a good wage, allow him to travel around the world, with a corporate Amex card, while he took the mic and railed against the very privacy-invading corporations who were paying his mortgage. Microsoft was for some reason keeping one of the biggest privacy curmudgeons in Europe on its payroll.

Microsoft has been, and continues to be, a total trainwreck on privacy. I always assumed that Microsoft kept Caspar around, in spite of his rough edges, because he provided the company with blunt, useful, internal feedback on their own products and services before they launched. If they listened to Caspar, it meant they would avoid a public flogging from public interest advocates.

Eventually, Microsoft fired him. I don't know if it was because the company tired of his public shenanigans, because he was, unlike many of his corporate shill peers at Microsoft, not willing to tow the obviously deceptive company line about its commitment to privacy, or, as Caspar later hinted, because he was increasingly voicing his concerns internally about FISA Amendments Act Section 702 and the ease with which the US government could spy on the cloud computing services, such as those provided by Microsoft, which were used by non-Americans.

But once Microsoft fired him, he dedicated himself to warning everyone he could about the way in which the NSA, through the FISA Amendments Act, could spy on the world. Caspar saw PRISM coming, and he tried to warn the world. But few would listen.

I remember in the week or two before the CCC Camp, in the summer of 2011, trying to convince Caspar to change the slides he planned to use for his talk (video) on FISA surveillance. They looked like a bottle of Doc Bronner's soap, words packed into every available inch of white space. They were impossible for the average attendee to understand, and would make him look crazy, as he stood on stage talking about a global NSA Internet dragnet. Caspar disagreed, and said that it was important to include as much useful information, the more the better, so that people watching at home could look it all up themselves.

Caspar knew he was right about what we now know as PRISM, he knew that the US government and US corporate interests were engaged in an active disinformation campaign to muddy the water on the issue of US government surveillance of cloud computing, and sadly, he could come off as a bit of a crank.

But he was right. He was so damn right.

Caspar taught me a lot, both by showing me what to do, and what not to do. I really looked up to him, and now he's gone.

Fuck.

I'll miss you Caspar.

Gone Fishin'

noreply@blogger.com (Christopher Soghoian) — Thu, 15 Aug 2013 19:30:00 +0000

This blog is not currently active. If you want to see what I'm upto, find me on Twitter at @csoghoian or at the ACLU Free Future blog.

Analyzing Yahoo's PRISM non-denial

noreply@blogger.com (Christopher Soghoian) — Sun, 09 Jun 2013 01:35:00 +0000

Today, Yahoo's General Counsel posted a carefully worded denial regarding the company's alleged participation in the NSA PRISM program. To the casual observer, it might seem like a categorical denial. I do not believe that Yahoo's denial is as straightforward as it seems.

Below, I have carefully parsed Yahoo's statement, line by line, in order to highlight the fact that Yahoo has not in fact denied receiving court orders under 50 USC 1881a (AKA FISA Section 702) for massive amounts of communications data.

We want to set the record straight about stories that Yahoo! has joined a program called PRISM through which we purportedly volunteer information about our users to the U.S. government and give federal agencies access to our user databases. These claims are false. [emphasis added]

No one has claimed that the PRISM program is voluntary. As the Director of National Intelligence has confirmed, the PRISM program involves court orders granted using Section 702 of the Foreign Intelligence Surveillance Act.

By falsely describing PRISM as a voluntary scheme, Yahoo's general counsel is then able to deny involvement outright. Very sneaky.

Yahoo! has not joined any program in which we volunteer to share user data with the U.S. government. We do not voluntarily disclose user information.

Again, PRISM has nothing to do with voluntary disclosures. These are compelled disclosures, pursuant to an order from the FISA court.

The only disclosures that occur are in response to specific demands.

The government can make a specific demand for information about all communications coming to or from a particular country. This is an empty statement.

And, when the government does request user data from Yahoo!, we protect our users.

Claiming to "protect our users" means nothing.

We demand that such requests be made through lawful means and for lawful purposes. We fight any requests that we deem unclear, improper, overbroad, or unlawful.

When the law allows blanket surveillance, "lawful means and lawful purposes" doesn't mean anything.

We carefully scrutinize each request, respond only when required to do so, and provide the least amount of data possible consistent with the law.

When a FISA court order demands blanket surveillance, responding only when required to do so is an empty promise, as is providing the least amount of data possible.

The notion that Yahoo! gives any federal agency vast or unfettered access to our users’ records is categorically false.

Elsewhere in the post, Yahoo's uses the terms "user data" and "user information". Why the sudden switch to the term "users' records"? This seems to deny participation in a Section 215 metadata disclosure program (see: the Verizon Business order revealed earlier this week), which has nothing to do with PRISM.

In any case, the PRISM scandal is not about unfettered access to users' data. It is about giving the government data in which one party of the communication is not in the US. Yahoo is not accused of giving the government unfettered access to communications where all parties are in the US.

Of the hundreds of millions of users we serve, an infinitesimal percentage will ever be the subject of a government data collection directive.

Note the use of the word directive in this statement, which does not mean voluntary. Now see below.

Where a request for data is received, we require the government to identify in each instance specific users and a specific lawful purpose for which their information is requested.

Here, Yahoo switches to using the term "requests" which are voluntary, not demands. The government is not obligated to describe "a specific legal purpose" when it has obtained a court order compelling the disclosure of data. It is only when the government is making a voluntary request of Yahoo that the company has the ability to set terms for the disclosure.

Then, and only then, do our employees evaluate the request and legal requirements in order to respond—or deny—the request.

Yahoo has flexibility when the government makes a request for data. The company has far less flexibility when it receives a court order demanding the disclosure of data.

We deeply value our users and their trust, and we work hard everyday to earn that trust and, more importantly, to preserve it.

If that were true, Yahoo would protect the privacy and security of its customers by enabling HTTPS by default for Yahoo Mail. Yahoo was the last big email provider to even offer HTTPS as an opt-in option, and has still not enabled it by default.

A few words on patronage

noreply@blogger.com (Christopher Soghoian) — Sat, 24 Nov 2012 22:14:00 +0000

Over the past couple years, I've taken several big companies to task for their woeful privacy and security practices. Just as it is important to call out these flaws, I believe it is also important to give companies credit when they go the extra mile to protect their customers.

When Google began protecting Gmail with HTTPS by default, I praised the company. When it started voluntarily publishing statistics for government requests, I again praised the company. When AT&T protected its customers' voicemail accounts from caller ID spoofing by forcing users to enter PINs, I praised the company. When Twitter asked the government to unseal the 2703(d) order that it had obtained as part of its investigation into Wikileaks, I praised the company. When Facebook started to offer HTTPS, and then this month enabled it by default, I praised the company. When Mozilla switched to encrypted search by default for Firefox, I praised the organization.

You get the idea.

Of course, just because I praise a particular action by a company, it doesn't mean that I am suddenly giving the company or its products my seal of approval. As an example, I'm of course glad that Facebook is enabling transport encryption to protect its customers' communications from network based interception. That doesn't mean I suddenly love Facebook, or bless the company's other business practices. Turning on HTTPS by default is a great move, but it isn't enough to get me to open a Facebook account, or trust the company with my data.

It is unfortunate then that I must defend myself against Nadim Kobeissi's latest attempt at reputation assassination.

Earlier this month, I praised Silent Circle for the company's fantastic law enforcement compliance policy. [Silent Circle sent me an early draft of their policy, sought feedback, and even accepted some of my suggestions]. Compared to the industry norm, in which companies merely disclose that they will hand over their customers' data to the government when forced to do so, Silent Circle's policy is an absolutely stellar example of the ways in which companies can approach this issue in a clear, transparent and honest manner.

I have spent several years researching the ways in which law enforcement agencies force service providers to spy on their customers. Most companies are not willing to discuss their law enforcement policies, let alone publish them online. It is for that reason that I praised Silent Circle - because they have set a great example that I hope other companies will follow.

However, as with the numerous other examples I highlighted above, just because I praise a particular action by a company, it doesn't mean that I now stand behind the company or its products.

Although I have praised Silent Circle's legal policies, I've made no public statements regarding the technical merits of their products. When I've been questioned by journalists about the extent to which consumers should trust the company's technology, I've been consistently conservative. As I recently told Ryan Gallagher at Slate:

Christopher Soghoian, principal technologist at the ACLU's Speech Privacy and Technology Project, said he was excited to see a company like Silent Circle visibly competing on privacy and security but that he was waiting for it to go open source and be audited by independent security experts before he would feel comfortable using it for sensitive communications.

Nadim has suggested that I am endangering my independence and that I have some kind of conflict of interest regarding Silent Circle, possibly because the company loaned me an iPod Touch so that I could get a chance to try out the iOS version of their software while they work out the kinks in the Android version. (How does Nadim even know the company loaned me an iPod? Because I disclosed it in a discussion with him on a public mailing list.)

Let me be perfectly clear. I am not a consultant to Silent Circle or any other company. I am not on an advisory board for Silent Circle or any other company. The only employer I have is the American Civil Liberties Union. Yes, I regularly talk with people who work at the company, and offer suggestions for ways that they can better protect the privacy of their customers. However, I regularly give solicited (and even more frequently, unsolicited) feedback to many companies, big and small. Most ignore me, but some occasionally change their practices. I am a privacy activist, and that is what I do.

Responding to Wired's ad hominem hatchet job

noreply@blogger.com (Christopher Soghoian) — Wed, 08 Aug 2012 10:08:00 +0000

I have long been a fan of Wired's coverage of privacy and security issues, particularly the insightful reporting and analysis by Ryan Singel, currently the editor of the Threat Level blog. It is for that reason that I am saddened to see Ryan stoop to twisting my words in support of a lengthy character assassination piece targeted against me.

Brief background

Two weeks ago, Wired published a glowing, 2000 word story by Quinn Norton about CryptoCat, an encrypted chat tool. Quinn was not the first journalist to shower praise upon Cryptocat -- writers at the New York Times and Forbes had previously done so too.

I subsequently published a lengthy blog post, which compared the media's coverage of Cryptocat, a relatively new, unproven security tool, to the media's previous fawning coverage of Haystack, a tool which, once analyzed by experts, was revealed to be pure snakeoil.

The message in my blog post -- that journalists risk exposing their readers to harm when they hype unproven security technologies -- was directed at the media as a whole. In support of my argument, I cited glowing praise for such technologies printed in the Guardian, the New York Times, Newsweek, Forbes and, Wired.

Today, Ryan Singel, the editor at Wired's Threat Level blog responded to my blog post, but incorrectly frames my criticism as if it were solely directed at Quinn Norton and her coverage of Cryptocat. In doing so, Ryan inaccurately paints me as a sexist, security-community insider who is unfairly criticizing a tool "created by an outsider to the clubby crypto community and one that’s written up by a woman and reviewed by a female security expert."

The importance of dissenting technical experts

One of the biggest criticisms of Norton's story I expressed in my blog post of was the fact that she did not quote a single technical expert that was critical of Cryptocat, even though there are quite a few who have been vocal with their concerns:

Other than Kobeissi, Norton's only other identified sources in the story are Meredith Patterson, a security researcher that was previously critical of Cryptocat who is quoted saying "although [Cryptocat] got off to a bumpy start, he’s risen to the occasion admirably" and an unnamed active member of Anonymous, who is quoted saying "if it's a hurry and someone needs something quickly, [use] Cryptocat."

As I also noted in my post:

Even though their voices were not heard in the Wired profile, several prominent experts in the security community have criticized the web-based version of Cryptocat. These critics include Thomas Ptacek, Zooko Wilcox-O'Hearn, Moxie Marlinspike and Jake Appelbaum.

Singel frames my criticism here as sexist. Meredith Patterson is a woman, whereas the Cryptocat critics I named were all men. Singel claims that, "Patterson, one of the all-too few female security researchers, doesn’t seem to count for much in Soghoian’s analysis." He adds later, "instead, Soghoian believes, Norton should have turned to one of four more vocal critics he names — all of them men."

As an initial matter, let me say that I have genuine respect for Meredith and her skills as a security researcher. We've known each other for several years, have attended several privacy conferences together, and have a shared goal in keeping the communications of users out of the prying hands of the government. Nowhere in my prior blog post do I dismiss Patterson's skills, credentials, or technical opinions.

My criticism of Norton's piece, in this respect, is not about the specific technical expert who is quoted as saying positive things about Cryptocat, but rather, the total lack of any dissenting quotes. If the rest of the security community were agnostic about the merits of Cryptocat, then it would perhaps be fine to quote a single technical expert who has positive things to say. In this case though, there are several technical experts who have deep concerns about the security of Cryptocat, experts whose research and views Wired has covered at length in the past.

As Singel has described it, I would have liked Norton to talk to a more more qualified expert, and to not print Patterson's opinions. That is not the case. I just think that a dissenting expert should be quoted too.

To summarize, the gender of the technical expert quoted saying positive things about Cryptocat has absolutely nothing at all to do with my belief that a responsible journalist would have spoken to, and quoted at least one technical expert who is critical of the tool. Even more so when the headline of the story is "This Cute Chat Site Could Save Your Life and Help Overthrow Your Government."

On the issue of privilege

In my blog post, I quoted from a few of Norton's recent tweets, in which she criticizes the crypto community, which she believes is filled with "privileged", "mostly rich 1st world white boys w/ no real problems who don't realize they only build tools [for] themselves."

After I published my blog post, Singel criticized me for quoting Norton's tweets, claiming that I was using "an outsider's critique of your boys club as a way to discredit them."

Although Singel clearly disagrees, I felt, and still feel that it is relevant to highlight the fact that Norton believes that the crypto community, and in particular, the critics of Cryptocat, are just privileged, paranoid geeks who have no real problems.

As I mentioned in my blog post, two of the most vocal critics of Cryptocat's web based chat app, Jake Appelbaum and Moxie Marlinspike, have faced pretty extreme real world problems of surveillance and government harassment.

After Appelbaum was outed by the press as as being associated with WikiLeaks, Twitter, Google and Sonic.net were forced to provide his communication records to the FBI as part of its investigation into WikiLeaks. At least one of Appelbaum's friends and colleagues has been forced to testify at a federal grand jury, and he has been repeatedly stopped at the border, harassed, and had digital devices seized by the authorities.

Likewise, for some time, Marlinspike was routinely stopped at the border by US authorities, had his laptop and phones searched, and in at least one case, was questioned by a US embassy official, who had a photo of Marlinspike at hand, before he could get on a plane back to the US.

While Appelbaum and Marlinspike have (thankfully) not been physically tortured by government agents, their paranoia and dedication towards improving the state of Internet security is by no means theoretical. Their concerns are legitimate, and their paranoia is justified.

On telling journalists to unplug

Singel's most vicious, yet totally unfair criticism relates to the two paragraphs that concluded my Cryptocat blog post:

Although human interest stories sell papers and lead to page clicks, the media needs to take some responsibility for its ignorant hyping of new security tools and services. When a PR person retained by a new hot security startup pitches you, consider approaching an independent security researcher or two for their thoughts. Even if it sounds great, please refrain from showering the tool with unqualified praise.
By all means, feel free to continue hyping the latest social-photo-geo-camera-dating app, but before you tell your readers that a new security tool will lead to the next Arab Spring or prevent the NSA from reading peoples' emails, step back, take a deep breath, and pull the power cord from your computer.

Singel states that the main point of my post "seemed to be to tell a woman to shut up and unplug from the net." He further twists my words by writing:

Moreover, Soghoian suggesting that if Quinn Norton ever wanted to write about about encryption tools in the future, she ought to "step back, take a deep breath, and pull the power cord from your computer" isn't just rude and obnoxious, it’s border-line sexist and an outright abuse of Soghoian's place in the computer security world."

The harsh words in my conclusion, which Singel quotes, were aimed at "the media." This of course includes Wired, but also many other journalists and news organizations who regularly publish stories on the latest new snake-oil product that uses "military-grade encryption."

In fact, the words "ignorant hyping" in the blog post's conclusion link to a recent New York Times article about Wickr, a new mobile app that the Times reveals will let "users transmit texts, photos and videos through secure and anonymous means previously reserved for the likes of the military and intelligence operatives."

(This is, of course, rubbish. There are no anonymity technologies that have been "reserved for the likes of the military and intelligence operatives.")

Finally, in support of his charge that I am sexist, Singel twists my words by stating that "Soghoian suggest[s] that if Quinn Norton ever wanted to write about about encryption tools in the future, she ought to 'step back, take a deep breath, and pull the power cord from your computer.'"

Let me be clear: Nowhere in my blog post do I tell Quinn that she should never again write about encryption tools. Instead, I warn journalists who are planning to write that "that a new security tool will lead to the next Arab Spring or prevent the NSA from reading peoples' emails." That is very different than "ever writing about encryption tools in the future."

Of course I want journalists to write about encryption, privacy, security and the importance of protecting data. I want users to be safe, and one of the best ways for them to discover and then adopt safe practices is by reading about them in the media.

(Strangely enough, Wired's chilling coverage this week of the devastating hack against ~~Mike~~ Mat Honan has been absolutely fantastic, offering a clear demonstration of how difficult it is for users to protect their data even when using tools and services created by billion dollar corporations.)

What I wish to avoid though, is news stories that hype technologies that simply cannot, and will not deliver what has been promised to users. By all means, please tell users about two-factor authentication, encrypted cloud backups with keys not known to providers, and VPN services. Just don't claim that these technologies will plunge the NSA into darkness or lead to the overthrow of authoritarian governments.

I do not hate female journalists

As an activist that uses media coverage to pressure companies to change their privacy invading practices, I regularly work with journalists around the world, feeding them stories, tips, and when they want them, quotes. In the more than six years that I have been working with the media (including Wired on countless occasions), never once has the gender of the reporter played any role in whether or not I went to them with a scoop, or returned their phone calls or emails.

The media are of course not equal in their understanding of technology or their willingness to dig deep into a tech issue. In my experience, gender plays absolutely no role in determining the quality of a tech journalist.

For example, of the entire news media, the What They Know team at the Wall Street Journal (Julia Angwin and Jennifer Valentino-DeVries) are by far the best in the business when it comes to covering privacy and security. They break major stories, do great investigative research, and routinely seek the confirmation of multiple technical experts in order to verify claims before they print them. On this beat, their coverage is first rate, and quite frankly, puts the New York Times, the Washington Post, Wired, Ars and others to shame. It is not surprising then, that when a great scoop lands in my lap, I take it to the WSJ first.

I judge, praise and criticize journalists on the tech beat based on the quality of their reporting, not by their gender. In this case, I criticized Quinn Norton's Wired story because it was deeply flawed, not because she is a woman. To claim otherwise is pure bullshit.

Tech journalists: Stop hyping unproven security tools

noreply@blogger.com (Christopher Soghoian) — Mon, 30 Jul 2012 21:43:00 +0000

Preface: Although this essay compares the media's similar hyping of Haystack and Cryptocat, the tools are, at a technical level, in no way similar. Haystack was at best, snake oil, peddled by a charlatan. Cryptocat is an interesting, open-source tool created by a guy who means well, and usually listens to feedback.

In 2009, media outlets around the world discovered, and soon began to shower praise upon Haystack, a software tool designed to allow Iranians to evade their government's Internet filtering. Haystack was the brainchild of Austin Heap, a San Francisco software developer, who the Guardian described as a "tech wunderkind" with the "know-how to topple governments."

The New York Times wrote that Haystack "makes it near impossible for censors to detect what Internet users are doing." The newspaper also quoted one of the members of the Haystack team saying that "It's encrypted at such a level it would take thousands of years to figure out what you’re saying."

Newsweek stated that Heap had "found the perfect disguise for dissidents in their cyberwar against the world’s dictators." The magazine revealed that the tool, which Heap and a friend had in "less than a month and many all-nighters" of coding, was equipped with "a sophisticated mathematical formula that conceals someone’s real online destinations inside a stream of innocuous traffic."

Heap was not content to merely help millions of oppressed Iranians. Newsweek quoted the 20-something developer revealing his long term goal: "We will systematically take on each repressive country that censors its people. We have a list. Don’t piss off hackers who will have their way with you.

The Guardian even selected Heap as its Innovator of the Year. The chair of the award panel praised Heap's "vision and unique approach to tackling a huge problem" as well as "his inventiveness and bravery."

This was a feel-good tech story that no news editor could ignore. A software developer from San Francisco taking on a despotic regime in Tehran.

There was just one problem: The tool hadn't been evaluated by actual security experts. Eventually, Jacob Appelbaum obtained a copy of and analyze the software. The results were not pretty -- he described it as "the worst piece of software I have ever had the displeasure of ripping apart."

Soon after, Daniel Colascione, the lead developer of Haystack resigned from the project, saying the program was an example of "hype trumping security." Heap ultimately shuttered Haystack.

After the proverbial shit hit the fan, the Berkman Center's Jillian York wrote:

I certainly blame Heap and his partners–for making outlandish claims about their product without it ever being subjected to an independent security review, and for all of the media whoring they’ve done over the past year.
But I also firmly place blame on the media, which elevated the status of a person who, at best was just trying to help, and a tool which very well could have been a great thing, to the level of a kid genius and his silver bullet, without so much as a call to circumvention experts.

Cryptocat: The press is still hypin'

In 2011, Nadim Kobeissi, then a 20 year old college student in Canada started to develop Cryptocat, a web-based secure chat service. The tool was criticized by security experts after its initial debut, but stayed largely below the radar until April 2012, when it won an award at the Wall Street Journal's Data Transparency Codeathon. Days later, the New York Times published a profile of Kobeissi, which the newspaper described as a "master hacker."

Cryptocat originally launched as a web-based application, which required no installation of software by the user. As Kobeissi told the New York Times:

"The whole point of Cryptocat is that you click a link and you’re chatting with someone over an encrypted chat room... That’s it. You’re done. It’s just as easy to use as Facebook chat, Google chat, anything.”

There are, unfortunately, many problems with the entire concept of web based crypto apps, the biggest of which is the difficulty of securely delivering javascript code to the browser. In an effort to address these legitimate security concerns, Kobeissi released a second version of Cryptocat in 2011, delivered as a Chrome browser plugin. The default version of Cryptocat on the public website was the less secure, web-based version, although users visiting the page were informed of the existence of the more secure Chrome plugin.

Forbes, Cryptocat and Hushmail

Two weeks ago, Jon Matonis, a blogger at Forbes included Cryptocat in his list of 5 Essential Privacy Tools For The Next Crypto War. He wrote that the tool "establishes a secure, encrypted chat session that is not subject to commercial or government surveillance."

If there is anyone who should be reluctant offer such bold, largely-unqualified praise to a web-based secure communications tool like Cryptocat, it should be Matonis. Several years ago, before he blogged for Forbes, Matonis was the CEO of Hushmail, a web-based encrypted email service. Like Cryptocat, Hushmail offered a 100% web-based client, and a downloadable java-based client which was more resistant to certain interception attacks, but less easy to use.

Hushmail had in public marketing materials claimed that "not even a Hushmail employee with access to our servers can read your encrypted e-mail, since each message is uniquely encoded before it leaves your computer." In was therefore quite a surprise when Wired reported in 2007 that Hushmail had been forced by a Canadian court to insert a backdoor into its web-based service, enabling the company to obtain decrypted emails sent and received by a few of its users.

The moral of the Hushmail story is that web based crypto tools often cannot protect users from surveillance backed by a court order.

Wired's ode to Cryptocat

This past Friday, Wired published a glowing, 2000 word profile on Kobeissi and Cryptocat by Quinn Norton. It begins with a bold headline: "This Cute Chat Site Could Save Your Life and Help Overthrow Your Government," after which, Norton describes the Cryptocat web app as something that can "save lives, subvert governments and frustrate marketers."

In her story, Norton emphasizes the usability benefits of Cryptocat over existing secure communications tools, and on the impact this will have on the average user for whom installing Pidgin and OTR is too difficult. Cryptocat, she writes, will allow "anyone to use end-to-end encryption to communicate without ... mucking about with downloading and installing other software." As Norton puts it, Cryptocat's no-download-required distribution model "means non-technical people anywhere in the world can talk without fear of online snooping from corporations, criminals or governments."

In short, Norton paints a picture in which Cryptocat fills a critical need: secure communications tools for the 99%, for the tl;dr crowd, for those who can't, don't know how to, don't have time to, or simply don't want to download and install software. For such users, Cryptocat sounds like a gift from the gods.

Journalists love human interest stories

Kobeissi presents the kind of human interest story that journalists dream about: A Lebanese hacker who has lived through 4 wars in his 21 years, whose father was killed, whose house was bombed, who was interrogated by the "cyber-intelligence authorities" in Lebanon and by the Department of Homeland Security in the US, and who is now building a tool to help others in the Arab world overthrow their oppressive governments.

As such, it isn't surprising that journalists and their editors aren't keen to prominently highlight the unproven nature of Cryptocat, even though I'm sure Kobeissi stresses it in every interview. After all, which journalist in their right mind would want to spoil this story by mentioning that the web-based Cryptocat system is vulnerable to trivial man in the middle, HTTPS stripping attacks when accessed using Internet Explorer or Safari? What idiot would sabotage the fairytale by highlighting that Cryptocat is unproven, an experimental project by a student interested in cryptography?

And so, such facts are buried. The New York Times waited until paragraph 10 in a 16 paragraph story to reveal that Kobeissi told the journalist that his tool "is not ready for use by people in life-and-death situations." Likewise, Norton waits until paragraph 27 of her Wired profile before she reveals that "Kobeissi has said repeatedly that Cryptocat is an experiment" or that "structural flaws in browser security and Javascript still dog the project." The preceding 26 paragraphs are filled with feel good fluff, including description of his troubles at the US border and a three paragraph no-comment from US Customs.

At best, this is bad journalism, and at worst, it is reckless. If Cryptocat is the secure chat tool for the tl;dr crowd, burying its known flaws 27 paragraphs down in a story almost guarantees that many users won't learn about the risks they are taking.

Cryptocat had faced extensive criticism from experts

Norton acknowledges in paragraph 23 of her story that "Kobeissi faced criticism from the security community." However, she never actually quotes any critics. She quotes Kobeissi saying that "Cryptocat has significantly advanced the field of browser crypto" but doesn't give anyone the opportunity to challenge the statement.

Other than Kobeissi, Norton's only other identified sources in the story are Meredith Patterson, a security researcher that was previously critical of Cryptocat who is quoted saying "although [Cryptocat] got off to a bumpy start, he’s risen to the occasion admirably" and an unnamed active member of Anonymous, who is quoted saying "if it's a hurry and someone needs something quickly, [use] Cryptocat."

It isn't clear why Norton felt it wasn't necessary to publish any dissenting voices. From her public Tweets, it is however, quite clear that Norton has no love for the crypto community, which she believes is filled with "privileged", "mostly rich 1st world white boys w/ no real problems who don't realize they only build tools [for] themselves."

Even though their voices were not heard in the Wired profile, several prominent experts in the security community have criticized the web-based version of Cryptocat. These critics include Thomas Ptacek, Zooko Wilcox-O'Hearn, Moxie Marlinspike and Jake Appelbaum. The latter two, coincidentally, have faced pretty extreme "real world [surveillance] problems" documented at length, by Wired.

Security problems with Cryptocat and Kobeissi's response

Since Cryptocat was first released, security experts have criticized the web-based app, which is vulnerable to several attacks, some possible using automated tools. The response by Kobeissi to these concerns has long been to point to the existence of the Cryptocat browser plugin.

The problem is that Cryptocat is described by journalists, and by Kobeissi in interviews with journalists, as a tool for those who can't or don't want to install software. When Cryptocat is criticized, Kobeissi then points to a downloadable browser plugin that users can install. In short, the only technology that can protect users from network attacks against the web-only Cryptocat also neutralizes its primary, and certainly most publicized feature.

Over the past few weeks, criticism of the web-based Cryptocat and its vulnerability to attacks has increased, primarily on Twitter. Responding to the criticism, on Saturday, Kobeissi announced that the the upcoming version 2 of Cryptocat will be browser-plugin only. ~~At the time of writing this essay, the Cryptocat web-based interface also appears to be offline.~~

Kobeissi's decision to ditch the no-download-required version of Cryptocat came just one day after the publication of Norton's glowing Wired story, in which she emphasized that Cryptocat enables "anyone to use end-to-end encryption to communicate without ... mucking about with downloading and installing other software."

This was no doubt a difficult decision for Kobeissi. Rather than leading the development of a secure communications tool that Just Works without any download required, he must now rebrand Cryptocat as a communications tool that doesn't require operating system install privileges, or one that is merely easier to download and install. This is far less sexy, but, importantly, far more secure. He made the right choice.

Conclusion

The technology and mainstream media play a key role in helping consumers to discover new technologies. Although there is a certain amount of hype with the release of every new app or service (if there isn't, the PR people aren't doing their jobs), hype is dangerous for security tools.

It is by now well documented that humans engage in risk compensation. When we wear seatbelts, we drive faster. When we wear bike helmets, we drive closer. These safety technologies at least work.

We also engage in risk compensation with security software. When we think our communications are secure, we are probably more likely to say things that we wouldn't if our calls were going over a telephone like or via Facebook. However, if the security software people are using is in fact insecure, then the users of the software are put in danger.

Secure communications tools are difficult to create, even by teams of skilled cryptographers. The Tor Project is nearly ten years old, yet bugs and design flaws are still found and fixed every year by other researchers. Using Tor for your private communications is by no means 100% safe (although, compared to many of the alternatives, it is often better). However, Tor has had years to mature. Tools like Haystack and Cryptocat have not. No matter how good you may think they are, they're simply not ready for prime time.

Although human interest stories sell papers and lead to page clicks, the media needs to take some responsibility for its ignorant hyping of new security tools and services. When a PR person retained by a new hot security startup pitches you, consider approaching an independent security researcher or two for their thoughts. Even if it sounds great, please refrain from showering the tool with unqualified praise.

By all means, feel free to continue hyping the latest social-photo-geo-camera-dating app, but before you tell your readers that a new security tool will lead to the next Arab Spring or prevent the NSA from reading peoples' emails, step back, take a deep breath, and pull the power cord from your computer.

The known unknowns of Skype interception

noreply@blogger.com (Christopher Soghoian) — Thu, 26 Jul 2012 21:15:00 +0000

Over the past few weeks, the technical blogosphere, and most recently, the mainstread media have tried to answer the question: What kind of assistance can Skype provide to law enforcement agencies?

Most of the stories have been filled with speculation, sometimes informed, but mostly not. In an attempt to paint as clear a picture as possible, I want to explain what we do and don't know about Skype and surveillance.

Skype has long provided assistance to governments

The Washington Post reported yesterday that:

Skype, the online phone service long favored by political dissidents, criminals and others eager to communicate beyond the reach of governments, has expanded its cooperation with law enforcement authorities to make online chats and other user information available to police
The changes, which give the authorities access to addresses and credit card numbers, have drawn quiet applause in law enforcement circles but hostility from many activists and analysts.

To back up its claim, the post cites interviews with "industry and government officials familiar with the changes" who "poke on the condition of anonymity because they weren’t authorized to discuss the issue publicly." Ugh.

However, a quick Google search for "Skype law enforcement handbook" quickly turns up an official looking document on the whistleblower website cryptome.org, dated October 2007, which makes it clear that Skype has long been providing the assistance that the Post claims is new.

From Skype's 2007 law enforcement handbook:

In response to a subpoena or other court order, Skype will provide:
• Registration information provided at time of account registration
• E-mail address
• IP address at the time of registration
• Financial transactions conducted with Skype in the past year, although details of the credit cards used are stored only by the billing provider used (for instance, Bibit, RBS or PayPal)
• Destination telephone numbers for any calls placed to the public switched telephone network (PSTN)
• All service and account information, including any billing address(es) provided, IP address (at each transaction), and complete transactional information

While Skype's law enforcement handbook suggests that the company does not have access to IP address session logs, high-profile criminal case from 2006 suggests that the company does.

Kobi Alexander, the founder of Comverse, was nabbed in Negombo, Sri Lanka yesterday by a private investigator. He is wanted by the US government in connection with financial fraud charges. He is accused of profiting from some very shady stock-option deals, to the detriment of Comverse shareholders. Once the deals became public and he was indicted, he resigned as CEO and fled the US.
Alexander was traced to the Sri Lankan capital of Colombo after he placed a one-minute call using Skype. That was enough to alert authorities to his presence and hunt him down.

This makes sense. Skype clients connect to Skype's central servers (so that users can make calls to non Skype users, and learn which of their friends are online and offline), and so the servers naturally learn the IP address that the user is connecting from. This is not surprising.

Skype voice call encryption

So while it is clear that Skype can provide government agencies with basic subscriber information and IP login info, what remains unclear is the extent to which governments can intercept the contents of Skype voice calls.

Skype has always been rather evasive when it comes to discussing this issue. Whenever questions come up, the company makes it a point to mention that it provides end to end encryption, but then dodges all questions about how it handles encryption keys.

Skype's strategy is genius - most journalists, even those that cover tech, know very little about the more granular aspects of cryptography. When Skype says it provides end to end call encryption, journalists then tell their readers that Skype is wiretapping proof, even though Skype never made that specific claim. Conveniently enough, Skype never bothers to correct the many people who have read a tad bit too much into the company's statements about security.

As Seth Schoen from EFF told Forbes recently, "my view is that Skype has gotten a reputation for impregnable security that it has never deserved." Exactly. Consumers think the service is secure, and Skype has absolutely no incentive to correct this false, yet positive impression.

The mud puddle test

Last year, I directed a bit of a media firestorm at Dropbox, after I filed an FTC complaint alleging that the company had been misleading its customers about the "military grade" security it used to protect the files uploaded by users. Earlier this year, the tech press started to ask similar questions about the cryptography and key management used by Apple's iCloud service.

Soon after, crytographer Matt Green proposed the 'mud puddle test' for easily determining if a cloud based storage solution has unencrypted access to your data.

1. First, drop your device(s) in a mud puddle.
2. Next, slip in said puddle and crack yourself on the head. When you regain consciousness you'll be perfectly fine, but won't for the life of you be able to recall your device passwords or keys.
3. Now try to get your cloud data back.
Did you succeed? If so, you're screwed. Or to be a bit less dramatic, I should say: your cloud provider has access to your 'encrypted' data, as does the government if they want it, as does any rogue employee who knows their way around your provider's internal policy checks.

Both Dropbox and iCloud fail the mud puddle test. If a user's laptop is destroyed and they forget their password, both services permit a user to reset the password and then download all of their data that was stored with the service. Both of these companies have access to your data, and can be forced to hand it over to the government. In contrast, SpiderOak, a competing online backup service (which I use) passes the test. If a SpiderOak user forgets their password, they lose their data.

What about Skype? After all, the company isn't an online backup service, but rather a communications service, right?

Well, as an initial matter, if you forget your password, Skype sends you a reset link by email, which lets you into your account, maintaining the same account balance and restoring your full contact list. Likewise, if you install Skype on a new computer, your contact list is downloaded, and you can conduct conversations that, to the other caller, will not in any way reveal that you recently installed Skype on a new device, or reset your password. It just works.

Encrypted communications require encryption keys.

Some protocols, like Off The Record (built into several Instant Messaging clients, but not to be confused with Google's fake, unencrypted Off The Record), random keys are created by the IM client, and then users are expected to exchange and verify them out of band (usually, by phone, or in person).

The OTR developers realized that users don't like manually verifying random alpha-numeric crypto fingerprints, and so the developers introduced a slightly easier method of verifying OTR keys in recent versions that uses secret questions or shared secrets selected by users (obviously, this is less secure, but more likely to be actually followed by users).

Another scheme, the ZRTP encrypted VOIP protocol, created by Phil Zimmermann of PGP fame avoids the static fingerprint method, and instead requires users to verify a random phrase at the beginning of each conversation. ZRTP (which is also used by Whisper Systems' RedPhone and the open source Jitsi chat tool) can rely on these pass phrase exchanges, because users presumably know each others' voices. Text based IM schemes don't have this voice recognition property, and so slightly heavier weight verification schemes are required there.

While these key/identity verification methods are a pain for users, they are important. Encryption is great, but without some method of authentication, it is not very helpful. That is, without authentication, you can be sure you have encrypted session, but you have no idea who is at the other end (someone pretending to be your friend, a government device engaging in a man in the middle interception attack, etc). The key verification/exchange methods used by OTR and ZRTP provide a strong degree of authentication, so that users can be sure that no one else is snooping on their communications.

Thanks for the crypto lesson

In contrast to the complex, user-visible fingerprint exchange and verification methods employed by OTR and ZRTP, Skype does nothing at all. Skype handles all the crypto and key exchange behind the scenes. When a Skype user installs the software on a brand new device and initiates a conversation with a friend already in their contact list, that friend is not told that the caller's device/software has a new crypto key and that it should be verified. Instead, the call just connects.

While we don't know the full details of how Skype handles its key exchange, what is clear is that Skype is in a position to impersonate its customers, or, should it be forced, to give a government agency the ability to impersonate its customers. As Skype acts as the gatekeeper of conversations, and the only entity providing any authentication of callers, users have no way of knowing if they're directly communicating with a friend they frequently chat with, or if their connection is being intercepted using a man in the middle attack, made possible due to the disclosure of cryptographic keys by Skype to the government.

I suspect that Skype does not create a new private encryption key for each device running Skype. Instead, my guess is that it creates a key once, when the user sets up their account, and then stores this online, along with the user's contact list. When the user installs Skype on a new device, the key is downloaded, along with all of their other account data. The user's public/private key pair would then be used to authenticate a session key exchange. If this is the design that Skype uses, the company can be compelled to disclose the private crypto keys it holds, allowing the government to impersonate users, and perform active man in the middle interception attacks against their communications.

One alternate, but equally insecure approach would be for the Skype clients to create a new public/private keypair each time the a user installs Skype on their computer and for Skype to digitally sign the user's public key using a certificate pre-installed in all Skype clients. In that scenario, while Skype the company won't have access to your private key, it will be able to sign public keys in your name for other people (including the government) that other Skype clients will accept without complaint. Such impersonation methods can then be used to perform man in the middle attacks.

Whatever the key exchange method that Skype uses, as long as users rely on Skype for all caller authentication, and as long as the company provides account access after a forgotten password, and seamless communications after the installation of Skype on a new computer, the company will fail the mud puddle test. Under such circumstances, Skype is in a position to give the government sufficient data to perform a man in the middle attack against Skype users.

Government agencies and encryption keys

Ok, so Skype has access to users' communications encryption keys (or can enable others to impersonate as Skype users). What does this mean for the confidentiality of Skype calls? Skype may in fact be telling the truth when it tells journalists that it does not provide CALEA-style wiretap capabilities to governments. It may not need to. If governments can can impersonate Skype users and perform man in the middle attacks on their conversations (with the assistance of broadband ISPs or wireless carriers), then they can decrypt the voice communications without any further assistance from Skype.

Do we know if this is happening? No. But that is largely because Skype really won't comment on the specifics of its interactions with governments, or the assistance it can provide. However, privacy researchers (pdf) have for many years speculated about governments compelling companies to hand over their own encryption keys or provide false certificates (pdf) for use in MiTM attacks. In such cases, when the requests come, there isn't really anything that companies can do to resist.

We need transparency

I suspect that 99% of Skype's customers have never given a moment's thought to the ease or difficulty with which government agencies can listen to their calls. Most likely use the service because it is free/cheap, easy, and enables them to talk to their loved ones with a minimum of hassle. There are, however, journalists, human rights activists and other at-risk groups who use Skype because they think it is more secure. In terms of Skype's hundreds of millions of users, these thousands of privacy-sensitive users are a tiny rounding error, a drop in the bucket.

Skype is not transparent about its surveillance capabilities. It will not tell us how it handles keys, what kind of assistance it provides governments, under what circumstances, or which governments it will and won't assist. Until it is more transparent, Skype should be assumed to be insecure, and not safe for those whose physical safety depends upon confidentiality of their calls.

Skype of course can't talk about the requests for assistance it has received from intelligence agencies, since such requests are almost certainly classified. However, Skype could, if it wished to, tell users about its surveillance capabilities. It doesn't.

I personally don't really care if Skype is resistant to government surveillance or not. There are other schemes, such as ZRTP, which are peer reviewed, open, documented protocols which activists can and should use. What I would like though, is for Skype to be honest. If it is providing encryption keys to governments, it should tell its customers. They deserve the truth.

Congressmen pushing awful cybersecurity bill fail cybersecurity 101

noreply@blogger.com (Christopher Soghoian) — Wed, 18 Apr 2012 15:36:00 +0000

Over the last several months, several cybersecurity bills have been proposed by various Congressional committees. One of the leading bills, the Cyber Intelligence Sharing and Protection Act (CISPA), has been proposed by Congressmen Mike Rogers (R-Mich.) and Rep. Dutch Ruppersberger (D-Md.). Many of the major civil liberties groups like EFF and ACLU have legitimately criticized the substance of the bill, which would give companies a free pass to share their customers' private information with the government.

I'm not going to get into the weeds and criticize specific portions of this bill. Instead, I want to make a broader point - Congress knows absolutely nothing about cybersecurity, and quite simply, until it knows more, and starts leading by example, it has no business forcing its wishes on the rest of us.

Congressmen Rogers and Ruppersberger are, respectively, the chairman and ranking member of the House Intelligence Committee. Although it is no secret that most members of Congress do not have technologists on staff providing them with policy advice, we can at least hope that the two most senior members of the Intelligence Committee have in-house technical advisors with specific expertise in the area of information security. After all, without such subject area expertise, it boggles the mind as to how they can at least evaluate and then put their names on the cybersecurity legislation that was almost certainly ghostwritten by other parts of the government - specifically, the National Security Agency.

So, given that these two gentlemen feel comfortable forcing their own view of cybersecurity on the rest of the public, I thought it would be useful to look at whether or not they practice what they preach. Specifically, how is their own information security. While I am not (for legal reasons) going to perform any kind of thorough audit of the two members' websites or email systems, even the most cursory evaluation is pretty informative.

HTTPS and Congressional websites

HTTPS encryption is the most basic form of security that websites should use - providing not only confidentiality, but also authentication and integrity, so that visitors to a site can be sure they are indeed communicating with the site they believe they are visiting. All big banks and financial organizations use HTTPS by default, Google has used it for Gmail since January 2010, and even the CIA and NSA websites use HTTPS by default (even though there is absolutely nothing classified on either of the two spy agency public sites). Some in Congress have even lectured companies about their lack of default HTTPS encryption - one year ago, Senator Schumer wrote to several major firms including Yahoo and Amazon, telling them that "providers of major websites have a responsibility to protect individuals who use their sites and submit private information. It’s my hope that the major sites will immediately put in place secure HTTPS web addresses.”

It is now 2012. HTTPS is no longer an obscure feature used by a few websites. It is an information security best practice and increasingly becoming the default across the industry. It is therefore alarming that not only do Congressional websites not offer HTTPS by default, but most members' websites don't support HTTPS at all.

Rogers

For example, the webserver running Congressman Mike Rogers's website seems to support HTTPS, however, attempting to visit https://mikerogers.house.gov/ (or https://www.mikerogers.house.gov/) will result in a certificate error.

This is perhaps a bit better than Congressman Roger's campaign website, which does not appear to be running a HTTPS webserver at all. Attempting to visit https://www.mikerogersforcongress.com/ results in a connection error.

Ruppersberger

When I manually tried to visit the HTTPS URL for Congressman Ruppersberger's website last night, it instead redirected me to the Congressional Caucus on Intellectual Property Promotion. Soon after I called the Congressman's office this morning to question his team's cybersecurity skills, the site stopped redirecting visitors, and now instead displays a misconfiguration error.

Congressman Dutch's campaign webserver appears to support HTTPS, but returns a certificate error.

Congressional websites could do HTTPS

While most Congressional websites return HTTPS certificate errors, the problems largely seem to be configuration issues. The webserver that runs all of the house.gov websites is listening on port 443 and it looks like Akamai has issued a wildcart *.house.gov certificate that can be used to secure any Congressional website. As an example, Nancy Pelosi's website supports HTTPS without any certificate errors (although it looks like there is some non-HTTPS encrypted content delivered from that page too.) This means that the Congressional IT staff can enable HTTPS encryption for Rogers, Ruppersberger and every other member without having to buy any new HTTPS certificates or setting up new webservers. The software is already all there - and the fact that these sites do not work over HTTPS connections already suggests that no one in the members' offices have asked for it. After all, if Nancy Pelosi's site can offer a secure experience, other members of Congress should be able to get similar protections too.

Remember SOPA

During the SOPA debate several months ago, a few members seemed to take pride in acknowledging their total ignorance regarding technology, proclaiming that they were not nerds, didn't understand the Internet, but even so still thought that SOPA was a good bill. Those members were justifiably ridiculed for ignoring technical experts while voting for legislation that would significantly and negatively impact the Internet.

Here, we have members who've not even bothered to ask the Congressional IT staff to make sure that their website support HTTPS, let alone use it by default, who are now telling the rest of the country that we should trust their judgement on the complex topic of cybersecurity.

Until the respective Congressional committees that deal with technology issues actually hire subject matter experts, any legislation they propose will lack legitimacy and, most likely, will probably be ineffective. Likewise, if Congress thinks that cybersecurity is a priority, perhaps it should lead by example.

The Daily Show with Jon Stewart
Get More: Daily Show Full Episodes,Political Humor & Satire Blog,The Daily Show on Facebook

Google's pro-privacy legal position re: DOJ could assist class action lawyers in search referrer privacy lawsuit

noreply@blogger.com (Christopher Soghoian) — Wed, 04 Apr 2012 18:28:00 +0000

In the summer of 2010, I filed a FTC complaint (pdf) against Google for deceiving its users about the extent to which it knowingly leaks user search queries to third parties via the referring header sent by web browsers. Shortly after my complaint was made public, a class action firm hit Google with a lawsuit over the practice.

Like many privacy class actions, the lawyers included every possible legal argument they could think of. One of their claims was that Google had violated the Stored Communications Act, which prohibits companies from sharing the contents of users' communications contents with other parties (even law enforcement agencies, unless they have a warrant).

The federal judge assigned to the case recently threw out all but one of the class action firm's claims, but but has permitted the case to continue solely focusing on Google's alleged violations of the Stored Communications Act. As such, one of the next big, important issues that the court is going to have to address is determining whether or not search queries are considered communications content under the Stored Communications Act.

As law professor Eric Goldman recently observed, "the SCA's poor drafting means that no one (including the judges) knows exactly what's covered by the statute." This is certainly true, and made worse by the fact that the statute hasn't really been updated since it was passed in 1986, long before the first web search engine or referrer header. It is for this very reason that DOJ has argued that the government should be able to get search engine query data without a warrant. Thankfully, Google disagrees.

Google: Search queries are content

At a recent event at San Francisco Law School, Richard Salgado, Google's Director of Law Enforcement and Information Security spoke publicly (for the first time) about Google's aggressively pro-privacy legal position on search queries and government access:

As far as search warrants and content go, Google and I think a lot of providers are taking this position, sees the 4th amendment particularly as it has been applied in the Warshak cases, as establishing that there is a reasonable expectation of privacy such that disclosure of the contents held with the third party is protected by the 4th Amendment. And not limited to email, but other material that is uploaded to the service provider to be handled by the service provider.

You hear a lot about ECPA about electronic communications service, ECS and remote computing sevice, RCS, and the crazy rules that apply [for example], the 180 day rule. I think most providers now, although I really should only speak to Google, view the way the case law is going and certaininly viewing the 4th Amendment as applying to any content that is provided by the user to the service, so that, for Google, would include things like Calendar and Docs, and all those others, even where there is not a communication function going on, that there's not another party involved in the Doc that you're uploading, the notes that you're keeping for yourself. It's still material that you've put with the service provider as part of the service that the company, in this case Google, is holding on your behalf. Its our view that that is protected by the 4th amendment, and unless one of the exceptions to the warrant requirement apply, its not to be disclosed to a government entity as a matter of compulsion.

Question: Where does search fall in that?

Answer: Search is one where we take a pretty hard stance, the same with other material, so we view search that its provided to us the way that other information is provided to us. That is very consistent with the ligitiation with the Department of Justice back in 2006.

Now, it seems pretty clear that Salgado is primarily talking about Google's view that the 4th Amendment protects user search queries, and is not arguing that they are communications content under the Stored Communications Act. Prior to this public event, I had heard reliable rumors that Google had adopted a warrant position for search queries based on the Stored Communications Act. Perhaps my sources were wrong, or perhaps Google realizes that it is going to be difficult to simultaneously argue two different positions on search engine queries and the SCA.

Even so, I suspect Google's legal team is still going to have a difficult time convincing the judge in this case that search engine queries are private enough for the company to repeatedly argue that they deserve warrant protections under the 4th Amendment, yet not private enough to deserve protections under the Stored Communications Act's prohibition against sharing communications content.

After all, as Al Gidari, Google's top privacy outside lawyer himself said at Brookings last year:

"[C]ontent is content, I don’t care how many times you try to repackage it into something else, content is still content, and the standards that we try to apply that give lesser protection to that content inevitably falls short, as well, when people stop and think about it."

ACLU docs reveal real-time cell phone location spying is easy and cheap

noreply@blogger.com (Christopher Soghoian) — Tue, 03 Apr 2012 16:25:00 +0000

"Technological progress poses a threat to privacy by enabling an extent of surveillance that in earlier times would have been prohibitively expensive."
-- US v. Garcia, 474 F. 3d 994 - Court of Appeals, 7th Circuit 2007

In 2009, I attended a surveillance industry trade show (the "wiretapper's ball") in Washington DC where I recorded an executive from Sprint describing, in depth, the location tracking capabilities his company provided to law enforcement agencies:

"[M]y major concern is the volume of requests. We have a lot of things that are automated but that's just scratching the surface. One of the things, like with our GPS tool. We turned it on the web interface for law enforcement about one year ago last month, and we just passed 8 million requests. So there is no way on earth my team could have handled 8 million requests from law enforcement, just for GPS alone. So the tool has just really caught on fire with law enforcement. They also love that it is extremely inexpensive to operate and easy, so, just the sheer volume of requests they anticipate us automating other features, and I just don't know how we'll handle the millions and millions of requests that are going to come in.
-- Paul Taylor, Electronic Surveillance Manager, Sprint Nextel.

The information that I gathered was one of the first real data points revealing the scale and ease with which law enforcement and intelligence agencies can now collect real-time location data from wireless phone carriers. This is because unlike wiretaps, there are no annual statistics produced by the courts that detail the number of location surveillance orders issued each year.

My disclosure of this information led to significant news coverage, but also to a citation from Judge Kozinski of the 9th Circuit, who observed in dissent in U.S. v. Pineda-Moreno that:

When requests for cell phone location information have become so numerous that the telephone company must develop a self-service website so that law enforcement agents can retrieve user data from the comfort of their desks, we can safely say that "such dragnet-type law enforcement practices" are already in use.

ACLU FOIA docs reveal other carriers have followed Sprint's lead

It appears that Sprint is not the only wireless company to provide law enforcement agencies with an easy way to track the location of targets in real-time.

Among the 5500 pages of documents obtained by the ACLU as part of a nationwide FOIA effort, are a few pages from Tucson AZ detailing (or at least hinting at) the real-time location tracking services provided to the government by the major wireless carriers.

AT&T's Electronic Surveillance Fee Schedule reveals that the company offers an "E911 Tool" to government agencies, which it charges $100 to activate, and then $25 per day to use.

While it is no secret that Sprint provides law enforcement agencies subscriber real-time GPS data via its "L-Site" website (read the L-site manual), Sprint's Electronic Surveillance Fee Schedule reveals that the company charges just $30 per month for access to this real-time data.

The documents from T-Mobile provides by far the greatest amount of information about the company's real-time location tracking capabilities. The company's Locator Tool service, which it charges law enforcement agencies $100 per day to access, generates pings at customizable 15 / 30/ 60 minute intervals, after which, the real-time location information is emailed directly to the law enforcement agency.

Unfortunately, Verizon's surveillance pricing sheets do not reveal any information about GPS tracking. It is almost certain that the company does provide real-time location data, but for now, we don't know how it is provided, or at what cost.

Federal judge: Google free to tell user about mysterious gov requests, likely related to Wikileaks

noreply@blogger.com (Christopher Soghoian) — Mon, 26 Mar 2012 21:13:00 +0000

Summary

In two 1-page orders issued today, a Federal judge in Virginia has (for a second time) ruled that Google is permitted to tell a customer (and only that customer) about two mysterious surveillance orders -- a 2703(d) order and a search warrant -- issued in June, 2011 for records (likely including communications content) associated with their Google account.

While Google is only permitted to notify the subscriber that was the subject of surveillance, that person is permitted to tell anyone else they wish, should they wish to do so.

Background

One month ago, a federal judge published two (pdf) orders (pdf) [hereafter the February 2012 orders], related to two previously secret surveillance orders obtained in June, 2011 by the government seeking data about a Google subscriber. In the two February 2012 orders, the judge ruled that Google could tell the user about the earlier surveillance orders.

Soon after, the government filed a motion with the court, seeking to clarify whether Google could tell any person about the orders, or merely the impacted user.

In the two orders issued today, the judge seems to have been convinced by the government's clarifying motion. Thus, in 14 days (unless the government appeals), Google will be free to tell the impacted user (and no one else) about the June 2011 surveillance orders.

This may involve Wikileaks

When Jeff Rollins at PaidContent first highlighted the existence of these two mysterious court orders, he suggested that they might be related to the Megaupload investigation. The Megaupload connection was mere speculation on his part (as he acknowledged), as there simply isn't anything solid in those two brief court orders that identifies a particular target.

However, for the reasons I outline below, I believe that these surveillance orders are actually related to the investigation of to Wikileaks.

First, in one of the February 2012 orders (page 2), the judge noted that "[t]he existence of the investigation in issue and the government’s wide use of § 2703(d) orders and other investigative tools has been widely publicized now."

The only high-profile federal investigation that I can think of in recent times involving 2703(d) orders is the government's investigation of individuals associated with Wikileaks. That is, while the Megaupload indictment was also filed in the Eastern District of Virginia, there has been little publicity surrounding the actual investigative legal instruments used in the case.

Specifically, I've not seen any published media report indicating that a 2703(d) order was used in that investigation. In contrast, the 2703(d) order issued to Twitter as part of the Wikileaks investigation has itself been a major story, as have the (failed) efforts of the ACLU, EFF and others to quash the order.

In December 2010, a judge from the same court issued a 2703(d) order to Twitter, forcing the company to disclose information about several users associated with Wikileaks. A month later, the Twitter judge agreed to unseal that order, allowing Twitter to notify the impacted individuals. Once existence of the surveillance order was made public, the media went crazy.

The Wall Street Journal later revealed that Google and California broadband provider Sonic had received similar requests as part of the same investigation. At the time of the WSJ report, those surveillance orders remained sealed.

Second, one persistent rumor in Washington DC over the past year has been that one of the main reasons DOJ has cited justifying the continued sealing of the Wikileaks/Google/Sonic orders is a fear of harassment from the Internet community directed at the prosecutors involved in the case.

As the WSJ revealed earlier this year, the address of Tracy Doherty McCormick, the prosecutor whose name was on the original Twitter order "was spread online, and the person's email account [tracy.mccormick@usdoj.gov] was subscribed to a pornography site." According to the unnamed officials quoted by the WSJ, she was also "bombarded with harassing phone calls."

The WSJ also reported that fear of similar harassment led "the government to take the rare step of keeping officials' names out of news releases and public statements when the government shut down the website Megaupload.com." It is likely that similar fears were the reason that no prosecutors names were listed in the recently published Lulzsec indictments.

Why do I mention this? Well, the two orders issued by the judge today specifically state that Google may share a copy of the 2703(d) order and search warrant with the impacted subscriber, but that the email address and name of the attesting official must be redacted first.

This suggests that someone at DOJ has told the judge they are fearful of retaliation from the Internet community -- thus also suggesting that this surveillance is related to a high-profile investigation of a target to whom Anonymous and other Internet activists may feel some sympathy. While this certainly could be the Megaupload case, I'd be willing to bet a few dollars that this involves Wikileaks.

Firefox switching to HTTPS Google search by default (and the end of referrer leakage)

noreply@blogger.com (Christopher Soghoian) — Wed, 21 Mar 2012 12:10:00 +0000

A few days ago, Mozilla's developers quietly enabled Google's HTTPS encrypted search as the default search service for the "nightly" developer trunk of the Firefox browser (it will actually use the SPDY protocol). This change should reach regular users at some point in the next few months.

This is a big deal for the 25% or so of Internet users who use Firefox to browse the web, bringing major improvements in privacy and security.

First, the search query information from these users will be shielded from their Internet service providers and governments who might be using Deep Packet Inspection (DPI) equipment to monitor the activity of users or censor and filter search results.

Second, the search query information will also be shielded from the websites that consumer visit after conducting a search. This information is normally leaked via the "referrer header". Google has in the past gone out of its way to facilitate referrer header based data leakage (which led to me filing a FTC complaint against the firm in 2010).

However, in October 2011, Google turned on HTTPS search by default for signed-in users, and at the same time, began scrubbing the search query from the non-HTTPS URL that HTTPS users are redirected to (and that subsequently leaks via the referrer header) before they reach the destination website:

Over the next few weeks, many of you will find yourselves redirected to https://www.google.com (note the extra “s”) when you’re signed in to your Google Account. This change encrypts your search queries and Google’s results page....
What does this mean for sites that receive clicks from Google search results? When you search from https://www.google.com, websites you visit from our organic search listings will still know that you came from Google, but won't receive information about each individual query.

At the time of the announcement, Google told the search engine optimization (SEO) industry (a community that very much wants to be able to continue to passively receive this kind of detailed user data) that the percentage of users whose search queries would be shielded would be a "single digit" -- and thus, at least 90% of Google users would still continue to unknowingly leak their search queries as they browse the web.

Shortly after Google's October announcement, search engine industry analyst Danny Sullivan told the SEO community that the days of referrer leakage were doomed:

By the future is clear. Referrer data is going away from search engines, and likely from other web sites, too. It’s somewhat amazing that we’ve had it last this long, and it will be painful to see that specific, valuable data disappear.
But from a consumer perspective, it’s also a better thing to do. As so much more moves online, referrers can easily leak out the location of things like private photos. Google’s move is part of a trend of blocking that already started and ultimately may move into the browsers themselves.

It looks like Danny was right.

Google's October 2011 decision to start proactively scrubbing search queries from the referrer header was a great first step, but a small percentage of Google's search users benefited. Now that Mozilla is switching to HTTPS search, hundreds of millions of Firefox users will have their privacy protected, by default.

The only surprising aspect to this otherwise great bit of good news is that the first major browser to use HTTPS search is Firefox and not Chrome. I reasonably assumed that as soon as Google's pro-privacy engineers and lawyers won the internal battle over those in the company sympathetic to needs of the SEO community, that Google's flagship browser would have been the first to ship HTTPS by default.

Just as it showed strong privacy leadership by being the first browser to embrace Do Not Track, Mozilla is similarly showing its users that privacy is a priority by being the first to embrace HTTPS search by default. For Mozilla, this is a clear win. For the Chrome team, whose browser has otherwise set the gold standard for security (and who have proposed and implemented a mechanism to enable websites to limit referrer leakage), this must be extremely frustrating and probably quite embarrassing. Hopefully, they will soon follow Mozilla's lead by protecting their users with HTTPS search by default.

(Just to be clear - the ultimate decision to enable HTTPS search by default was largely in the hands of Google's search engineers, who are responsible for dealing with the increased traffic. Mozilla's privacy team deserves the credit for pressuring Google, and Google's search engine team deserve a big pat on the back for agreeing to cope with encrypted searches from hundreds of millions of users.)

FBI seeks warrant to force Google to unlock Android phone

noreply@blogger.com (Christopher Soghoian) — Wed, 14 Mar 2012 14:47:00 +0000

Today, I stumbled across a recent FBI application and accompanying affidavit for a search warrant ordering Google to unlock a screen-locked Android phone. The application asks Google to: "provide law enforcement with any and all means of gaining access, including login and password information, password reset, and/or manufacturer default code ("PUK"), in order to obtain the complete contents of the memory" of a seized phone.

The phone in question was seized from a gentleman named Dante Dears, a founding member of the "Pimpin' Hoes Daily" street gang. On January 17, 2012, a cellphone was seized from Dears by an FBI agent, who then obtained a search warrant to look through the device. According to the affidavit, the technicians at the FBI Regional Computer Forensics Lab (RCFL) were unable to get past the electronic "pattern lock" access controls protecting the phone (apparently, entering multiple incorrect unlock sequences will lock the memory of the phone, which can then only be accessed by entering the user's Gmail username and password).

So why is this interesting and noteworthy?

First, it suggests that the FBI's computer forensics lab in Southern California is unable, or unwilling to use commercially available forensics tools or widely documented hardware-hacking techniques to analyze seized phones and download the data from them.

Second, it suggests that a warrant might be enough to get Google to unlock a phone. Presumably, this is not the first time that the FBI has requested Google unlock a phone, so one would assume that the FBI would request the right kind of order. However, we do not know if Google has complied with the request. Given that an unlocked smartphone will continue to receive text messages and new emails (transmitted after the device was first seized), one could reasonably argue that the government should have to obtain a wiretap order in order to unlock the phone.

Third, on page 13 of the warrant application, the government asks that the owner of the phone not be told about the government's request to unlock his phone. It is surprising then that the warrant and the associated affidavit have not been sealed by the court.

Do Not Track: First they ignore you, then they ridicule you, then they fight you, then you win.

noreply@blogger.com (Christopher Soghoian) — Thu, 23 Feb 2012 14:18:00 +0000

In July of 2009, my friend and research collaborator Sid Stamm helped me to put together a prototype Firefox add-on that added two headers to outgoing HTTP requests:

X-Behavioral-Ad-Opt-Out: 1
X-Do-Not-Track: 1

The idea for the Do Not Track header came from a conversation I'd had with security researcher Dan Kaminsky in March of 2009.

A few months after we released the DNT prototype, I started working at the FTC. Once there, Ashkan Soltani and I evangelized the header-based mechanism as a superior solution to the flawed opt-out cookies that the industry had grudgingly delivered. In December 2010, the FTC issued a privacy report that called for a "do not track" system that would enable people to avoid having their actions monitored online.

Today, the Obama Administration, the FTC and the advertising industry will announce that the last remaining web browser (Chrome) will support the Do Not Track header, and that the major online advertising networks will look for and respect it.

The total time, from the first conversation about the concept to a White House press conference announcing broad industry support? 3 years. Decades in Internet time, but this is extremely quick by Washington, DC standards.

First they ignore you:

In mid July 2009, the Future of Privacy Forum organized a meeting and conference call in which I pitched the header concept to a bunch of industry players, public interest groups, and other interested parties. I was perhaps slightly over-dramatic when I told them that the "day of reckoning was coming", for opt out cookies, and that it was time to embrace a header based mechanism...none of the advertising firms showed any interest in the header.

Then they laugh at you:

[Microsoft Vice President Dean] Hachamovitch said it’s naive to simply trust that the tracking sites will obey an anti-tracking signal. “We don’t have ‘do not send me pop-up window’ HTTP headers,” said Hachamovitch, speaking at UC Berkeley. “We just have pop-up blockers.” Similarly, he noted, there’s no “Do Not Phish Me” button on browsers.

Then they fight you:

The Interactive Advertising Bureau, which represents online advertisers, said "there is currently no definition" of what advertisers should do when receiving the do-not-track notification. "It's like sending a smoke signal in the middle of Manhattan; it might draw a lot of attention, but no one knows how to read the message," said Mike Zaneis, senior vice president of the organization.

Then you win:

A coalition of Internet giants including Google Inc. has agreed to support a do-not-track button to be embedded in most Web browsers—a move that the industry had been resisting for more than a year.

How long does it take for the FTC to investigate a company?

noreply@blogger.com (Christopher Soghoian) — Wed, 08 Feb 2012 18:45:00 +0000

The Federal Trade Commission is the nation's premier privacy enforcer. In the last few years, it has gone after Facebook, Google, Twitter and several other firms for violating consumers' privacy or deceiving them about the degree to which they protect that privacy. To outsiders, the FTC can seem highly secretive - it doesn't announce when it opens an investigation, only when an investigation ends in a settlement, a lawsuit, or a public closing letter.

As a result, although the newspapers and blogs may be filled with stories about a particular privacy firestorm, there is no way to know if the FTC is investigating a company. A year or two later, the FTC might announce a settlement, or, the FTC may quietly close an investigation, without ever tipping the public off to the fact that agency staff spent months investigating the company.

I spent a year working in the FTC's Division of Privacy and Identity Protection between 2009-2010, where I got to assist with several important privacy investigations. I saw first hand how frustrating it is for staff, when advocates, the media and Members of Congress demand that the FTC investigate a company or worse, criticize the FTC for doing nothing, when FTC staff are already several months into a complex investigation.

In order to try and help the general public better understand this topic, I recently sought and obtained (via FOIA) the official Matter Initiation Notices (pdf) filed by FTC staff when they formally opened investigations into all of the major privacy-related cases settled during the past few years.

As these documents show, even the fastest privacy case (Google Buzz) took a year from start to finish, while others, such as Facebook (2.3 years) and ControlScan (2.7 years) took far longer.

The take-home lesson from this data? The FTC's investigations are not quick. Given that there are just a couple dozen attorneys in the Division, this isn't surprising. If we want better (and faster) privacy enforcement, giving the FTC more money to hire additional staff would be a great first step.

Sprint recklessly exposed Carrier IQ logged URL data to easy government access

noreply@blogger.com (Christopher Soghoian) — Mon, 19 Dec 2011 07:00:00 +0000

In recent weeks, there has been considerable controversy around Carrier IQ and the data collected by it and the wireless phone companies who have partnered with the firm. Now that class action lawsuits have been filed, and the FTC is reportedly probing the company, one of the most important questions will be: What is the harm?

As I will attempt to argue in this blog post, by allowing Carrier IQ to collect and retain private user data (such as URLs of pages viewed), Sprint recklessly exposed this sensitive information, which would normally require a court order for the government to obtain, to access with a mere subpoena.

Last week, technical experts Ashkan Soltani and Peter Eckersley reported that Carrier IQ's software was, in some cases, collecting keystrokes and the contents of (SMS) text messages. A 19-page report (pdf) released by Carrier IQ confirmed the researchers' claims, putting the blame on a technical bug and accidental overlogging by Sprint or HTC.

For the purpose of this blog post, lets give Carrier IQ the benefit of the doubt. Instead, it is sufficient to focus our attention on one form of intentional data collection that Carrier IQ and its partner Sprint have acknowledged: the URLs of websites visited by handset owners. [There are others kinds of data that the company has intentionally logged too, for example, location data, but we don't know as much about this right now, so I'm focusing my analysis on URLs]

Carrier IQ and Sprint: Yeah, we log URLs

In a letter to Senator Franken (pdf) last week, Carrier IQ acknowledged that its software has been used by one wireless carrier to collect the URLs of webpages viewed by subscribers:

Embedded versions of IQ Agent allow for the collection of URLs if requested by a Network Operator in a profile. These can be collected together with performance metrics so that Network Operators can determine how devices on its network perform for specific web sites... The profile specified by the Network Operator and loaded on the device dictates if this information is actually gathered. The IQ Agent cannot read or copy the content of a website. Only one of Carrier IQ's customers has requested a profile to collect URLs of websites visited on devices on its network.

In its letter to Senator Franken (pdf), Sprint acknowledged that it was the wireless carrier that collected URLs:

Sprint already knows the website of a URL of a website that a user is trying to reach from routing the request on its network. This information may be collected through the Carrier IQ software as part of a profile established to troubleshoot website loading latencies or errors experienced by a population of subscribers.

Let us ignore the fact that in the same letter, Sprint falsely denies collecting users' search query information (the search terms are in the Google/Bing URL), that it failed to disclose that Sprint collects through Carrier IQ the URLs of webpages viewed over encrypted HTTPS connections which it would never learn by watching the network, or, that it probably also gets through Carrier IQ the URLs accessed by handset owners when they are using WiFI and not Sprint's network. While these are interesting points (and show that Sprint is either lying to a Senator, or their legal team is embarrassingly ignorant about technology), they are unnecessary for our analysis.

It is also worth mentioning, although similarly unnecessary for our analysis, that Sprint's Electronic Surveillance Manager revealed in comments at the ISS World surveillance conference in 2009 that Sprint allows its marketing department to look through the logs of URLs viewed by its subscribers:

On the Sprint 3G network, we have IP data back 24 months, and we have, depending on the device, we can actually tell you what URL they went to ... If [the handset uses] the [WAP] Media Access Gateway, we have the URL history for 24 months ... We don't store it because law enforcement asks us to store it, we store it because when we launched 3G in 2001 or so, we thought we were going to bill by the megabyte ... but ultimately, that's why we store the data ... It's because marketing wants to rifle through the data.

Legal protections for URL data under US privacy law

It is beyond a cliche at this point to complain that our primary electronic privacy law dates from 1986, and hasn't been substantially updated since. This law not only differs in the legal protections offered to data based on whether it is is content or non-content, but also, based on what kind of company is holding the data.

As a Sprint customer, I am obviously unhappy about the fact that that the company voluntarily logs and retains the URLs that subscribers visit - which are subsequently available to the government. However, I can get at least a tiny bit of comfort from the fact that the Electronic Communications Privacy Act requires a court order issued under 18 USC 2703(d) before Sprint can be forced to disclose these records to law enforcement agencies.

Furthermore, if Sprint wished to do so, it could probably argue that URLs contain communications content, and thus should only be disclosed pursuant to a probable cause warrant. [DOJ has acknowledged in its Search and Seizure manual that URLs can contain content, at least in context of real-time intercepts via a pen register]. However, given Sprint's general pro-government approach to privacy, I wouldn't expect them to lift a finger to protect their customers.

Carrier IQ and ECPA

What about Carrier IQ? Does the government need a court order to get URLs when held by the company?

To be considered a "remote computing service" (RCS) or an "electronic communication service" (ECS) provider under the Electronic Communications Privacy Act (ECPA), you need to actually provide services to the public. Carrier IQ does not do this -- its customers are wireless carriers. On this point alone, user data held by Carrier IQ is simply not subject to the limited protections of ECPA.

Furthermore, even if we ignore the important requirement relating to providing services to the public, a service provider also has to actually provide the ability to send or receive a users' communication for it to be considered an ECS under the law. See Sega Enterprises Ltd. v. MAPHIA, 948 F. Supp. 923, 930-31 (N.D. Cal. 1996) (video game manufacturer that accessed private email of users of another company's bulletin board service was not a provider of electronic communication service); State Wide Photocopy, Corp. v. Tokai Fin. Servs., Inc., 909 F. Supp. 137, 145 (S.D.N.Y. 1995) (financing company that used fax machines and computers but did not provide the ability to send or receive communications was not provider of electronic communication service).

Since Carrier IQ is merely covertly logging the URLs that consumers are viewing, rather than actually delivering web pages to the end user, they also aren't covered under ECPA.

So what?

As Carrier IQ is neither an RCS or ECS under ECPA, any data held by the company can be obtained by the government with a mere subpoena (and potentially, but I'm not as sure of this, by a civil litigant too, such as a divorce lawyer).

As Sprint opted to have user data sent to Carrier IQ, where it was held for 30-45 days, rather than having the carrier IQ software send the data directly to Sprint's servers, I believe that Sprint recklessly exposed this private information to easy access by the government without a court order. There are plenty of ways that the company could have guaranteed that this data would always remain protected under ECPA -- but it didn't do so.

Likewise, while Sprint claims in its letter to Senator Franken that it tells its customers in its privacy policy that it collects information about the sites that they visit, it never discloses to subscribers that this private data is collected and stored by a third party, or the important way this will enable government access to that data. Sprint needlessly kept its customers in the dark about the ways in which the firm was exposing their data to government access.

In its letter to Senator Franken, Carrier IQ denied getting any requests from law enforcement agencies for user data. Sprint had to issue a much more delicately worded statement: it has not disclosed Carrier IQ data to law enforcement (the reason for this careful wording, I suspect, is the presence of 110 employees in Sprint's Electronic Surveillance team who do nothing but supply user data to law enforcement and intelligence agencies).

Although the recent FOIA response that Muckrock received suggests that the FBI has at least some interest in Carrier IQ data, if we rely on the statements of Carrier IQ and Sprint, then, at least as it relates to URL data, the risks I have described in this blog post are largely theoretical. Even so, it doesn't change the fact that Sprint has demonstrated an extremely cavalier attitude towards user privacy.

In a best case scenario, Sprint's legal team simply didn't consider the ECPA/law enforcement related implications of using Carrier IQ's technology. In a worst case scenario, they knew what they were doing, and didn't care. In either case, the company should be held responsible.

Commerce Dept: export licenses for intercept tech have "exploded" over last 2,3 years

noreply@blogger.com (Christopher Soghoian) — Fri, 16 Dec 2011 23:00:00 +0000

Earlier this year, the Commerce Department's Bureau of Industry and Security held a two-day Conference on Export Controls and Policy. It included a workshop specifically focused on the rules governing the export of encryption technologies (which include intercept equipment). The full transcript can be found here: part 1 (pdf), part 2 (pdf).

As a non-lawyer, and non-expert in export control regulations, I was pretty surprised to learn that the government already strictly regulates the export of covert communications surveillance technology. What this means, of course, is that the Commerce Department already has a list of every foreign buyer of US made covert surveillance technology. Unfortunately, they won't provide this information to the public, and as far as I know, they won't provide it in response to FOIA requests.

In any case, reading through the transcript of the event, the following section caught my eye, as it specifically addressed the regulations that apply to surreptitious listening technology:

Michael Pender: Licenses [for "surreptitious listening" technology] are required for export to all end users, all destinations, and there's a general policy of denial.

The exceptions are for U.S. government agencies or communication-service providers there in the normal course of their business. So, if you're representing a U.S. law-enforcement agency and you're partnering with some other organization in another country and you need to send something out of the county, you know, contact us. Licenses are authorized for that situation.

If you represent a telecommunications company and you receive court orders for wiretaps from the local law enforcement and you have to comply with those court orders, you know, that's one of the few circumstances in which we can grant a license.

And you wouldn't think there would be that many licenses for these products in general in a year, but the rate at which they're coming in has just exploded over the course of the last 2, 3 years. I mean, I think I went from getting one a year to like five times as many, and then again, it's at least doubled or tripled in just the last year.

Twitter's privacy policy and the Wikileaks case

noreply@blogger.com (Christopher Soghoian) — Sat, 12 Nov 2011 01:12:00 +0000

Summary: The federal judge in the Wikileaks case cited in his order a version of Twitter's privacy policy from 2010, rather than the very different policy that existed when Appelbaum, Gonggrijp and Jonsdottir created their Twitter accounts back in 2008. That older policy actually promised users that Twitter would keep their data private unless they violated the company's terms of service. It is unclear how the judge managed to miss this important detail.

Earlier this week, a federal judge in Virginia handed down an order in the high-profile Twitter/Wikileaks case. That order has already been widely covered by the media, so I won't summarize it here.

In ruling that Appelbaum, Gonggrijp and Jonsdottir did not have a reasonable expectation of privacy in the IP addresses that Twitter had collected, the judge specifically highlighted the existence of statements about IP address collection in Twitter's privacy policy.

(from page 3 of the order)

The judge noted that Twitter reveals in its privacy policy that it collects "many types of usage information, including physical location, IP address, browser type, the referring domain ..." To support this claim, the judge cited the "Bringola declaration" (pdf), which is a collection of screenshots from Twitter's website produced by a paralegal working for Appelbaum's lawyer.

The privacy policy reproduced in the Bringola declaration and cited by the judge was effective as of November 16, 2010, and appears to have been the current privacy policy in March of 2011 when the paralegal made the screenshots. That privacy policy included the following "Log Data" section:

Our servers automatically record information ("Log Data") created by your use of the Services. Log Data may include information such as your IP address, browser type, the referring domain, pages visited, your mobile carrier, device and application IDs, and search terms. Other actions, such as interactions with our website, applications and advertisements, may also be included in Log Data. If we haven’t already deleted the Log Data earlier, we will either delete it or remove any common account identifiers, such as your username, full IP address, or email address, after 18 months.

There is a slight problem with relying on a privacy policy created on November 16, 2010 to decide the reasonable expectation of privacy of these three individuals: They created their Twitter accounts several years before the document was written.

According to the useful website howlonghaveyoubeentweeting.com, Appelbaum's Twitter account was created on February 23, 2008, Gonggrijp created his on September 26, 2008, and Jonsdottir created hers on November 14, 2008.

Thankfully, Twitter seems to archive all the old versions of their privacy policy. It would appear that all three individuals would have "agreed to" (ignoring the fact that none of them likely read the thing in the first place) Version 1 of the privacy policy, dated May 14, 2007. The "Log data" section of that policy reads as follows:

When you visit the Site, our servers automatically record information that your browser sends whenever you visit a website ("Log Data" ). This Log Data may include information such as your IP address, browser type or the domain from which you are visiting, the web-pages you visit, the search terms you use, and any advertisements on which you click. For most users accessing the Internet from an Internet service provider the IP address will be different every time you log on. We use Log Data to monitor the use of the Site and of our Service, and for the Site's technical administration. We do not associate your IP address with any other personally identifiable information to identify you personally, except in case of violation of the Terms of Service.

There are a few things worth noting here:

The term "referring domain" appears in privacy policy cited by the judge in his court order, but not in Version 1 of the Twitter privacy policy. This strongly suggests that the judge is citing a newer version of the Twitter policy. The term appears to have been added in Version 2 of the privacy policy, dated November 18, 2009.
In Version 1 of its policy, Twitter promised its users that it would not associate their IP addresses with any other personally identifiable information sufficient to identify them personally, unless they violated the Twitter terms of service. This pro-user sentence was removed in Version 2 of Twitter's privacy policy, one year later.
The government has not alleged that any of the 3 individuals violated Twitter's terms of service. As such, it would appear that they could reasonably rely on Twitter's claims that it wouldn't associate their retained IP address information with their existing account records or any other personally identifiable information.

This is very interesting.

The old version of Twitter's policy that the three individuals "agreed" to also includes the following paragraph about updates to the document:

This Privacy Policy may be updated from time to time for any reason; each version will apply to information collected while it was in place. We will notify you of any material changes to our Privacy Policy by posting the new Privacy Policy on our Site. You are advised to consult this Privacy Policy regularly for any changes.

Note, Twitter didn't say that it would send out emails to users when it updated its privacy policy, instead, it advised users to revisit the site on a regular basis to see if the policy had changed. How this sentence passed the laugh test at Twitter's HQ, I do not know.

In subsequent edits to the policy, Twitter reworded this section, so that it now reads:

We may revise this Privacy Policy from time to time. The most current version of the policy will govern our use of your information and will always be at https://twitter.com/privacy. If we make a change to this policy that, in our sole discretion, is material, we will notify you via an @Twitter update or e-mail to the email associated with your account. By continuing to access or use the Services after those changes become effective, you agree to be bound by the revised Privacy Policy.

Got that? As of Version 2 of Twitter's privacy policy, merely by continuing to use Twitter, you agree to be bound by whatever the company adds to the policy. Oh, and it is up to the company to decide if the changes to the policy are important enough to justify telling users.

I know that I am not the first researcher to point out how stupid privacy policies are, or that no one reads them. Many others have done it, and done so far more eloquently than me. My goal in writing this blog post is simple: Not only is a federal judge ruling that 3 individuals have no reasonable expectation of privacy with regard to the government getting some of their Internet transaction data, but the judge isn't even citing the right version of a widely ignored privacy policy to do so. If the judge were to examine the privacy policy that existed when these three targets signed up for a Twitter account, he might decide that they do in fact have a reasonable expectation of privacy and that the government needs a warrant to get the data.

Two honest Google employees: our products don't protect your privacy

noreply@blogger.com (Christopher Soghoian) — Wed, 02 Nov 2011 21:26:00 +0000

Two senior Google employees recently acknowledged that the company's products do not protect user privacy. This is quite a departure from the norm at Google, where statements about privacy are usually thick with propaganda, mistruths and often outright deception.

Google's products do not meet the privacy needs of journalists, bloggers, small businesses (or anyone else concerned about government surveillance).

Last week, I published an op-ed in the New York Times that focused on the widespread ignorance of computer security among journalists and news organizations. Governments often have no need to try and compel a journalist to reveal the identity of their sources if they can simply obtain stored communication records from phone, email and social networking companies.

Will DeVries, Google's top DC privacy lobbyist soon posted a link to the article on his (personal) Google+ page, and added the following comment:

I often disagree with Chris, but when he's right, he's dead right. Journalists (and bloggers, and small businesses) need to take a couple hours and learn to use free, widely available security measures to store data and communicate.

Let me first say that I really respect Will. Many of the people in Google's policy team default to propaganda mode when questioned. Will does not do this - he either speaks truthfully, or declines to comment. I wish companies would hire more people like him, as they significantly boost the credibility of the firm among privacy advocates.

Regarding Will's comment: If Google's products were secure out of the box, journalists would not need to "take a couple hours" to learn to protect their data and communications. Will does not tell journalists to ditch their insecure Hotmail accounts and switch to Gmail, or to ditch their easily trackable iPhones and get an Android device. Likewise, he does not advise people to stop using Skype for voice and video chat, and instead use Google's competing services. He doesn't do that, because if he described these services as more secure and resistant to government access than the competition, he'd be lying.

Google's services are not secure by default, and, because the company's business model depends upon the monetizaton of user data, the company keeps as much data as possible about the activities of its users. These detailed records are not just useful to Google's engineers and advertising teams, but are also a juicy target for law enforcement agencies.

It would be great if Google's products were suitable for journalists, bloggers, activists and other groups that are routinely the target of surveillance by governments around the world. For now, though, as Will notes, these persons will need to investigate the (non-Google) tools and methods with which they can protect their data.

Google business model is in conflict with privacy by design

At a recent conference in Kenya, Vint Cerf, one of the fathers of the Internet and Google's Chief Internet Evangelist spoke on the same panel as me. We had the following exchange over the issue of Google's lack of encryption for user data stored on the company's servers (I've edited it to show the important bits about this particular topic - the full transcript is online here).

Me:

[I]t's very difficult to monetize data when you cannot see it. And so if the files that I store in Google docs are encrypted or if the files I store on Amazon's drives are encrypted then they are not able to monetize it....And unfortunately, these companies are putting their desire to monetize your data over their desire to protect your communications.

Now, this doesn't mean that Google and Microsoft and Yahoo! are evil. They are not going out of their way to help law enforcement. It's just that their business model is in conflict with your privacy. And given two choices, one of which is protecting you from the government and the other which is making money, they are going to go with making money because, of course, they are public corporations. They are required to make money and return it to their shareholders.

Vint Cerf:

I think you're quite right, however that, we couldn't run our system if everything in it were encrypted because then we wouldn't know which ads to show you. So this is a system that was designed around a particular business model.

Google could encrypt user data in storage with a key not known to the company, as several other cloud storage companies already do. Unfortunately, Google's ad supported business model simply does not permit the company to protect user data in this way. The end result is that law enforcement agencies can, and regularly do request user data from the company -- requests that would lead to nothing if the company put user security and privacy first.

The forces that led to the DigiNotar hack

noreply@blogger.com (Christopher Soghoian) — Mon, 19 Sep 2011 12:45:00 +0000

Last week, the New York Times finally covered the DigiNotar hacks, more than two weeks after security experts and the tech media first broke the story. Unfortunately, the top 2-3 newspapers in the US (which is what legislative staff, regulators and policy makers read) have missed most of the important details. The purpose of this blog post is to fill in those gaps, providing key context to understand this incident as part of the larger Internet trust (and surveillance) debate.

Lawful access

As consumers around the world have embraced cloud computing, large Internet firms like Google, Facebook, Twitter, Yahoo, all of them based in the United States, increasingly hold users' most private documents and other data. This has been a boon for law enforcement agencies, which can often obtain these files without a court issued search warrant, or have to provide the investigated individual with the kind of prompt notice that would otherwise occur had their home been searched.

Law enforcement and intelligence agencies in the US, EU, Canada, Brasil, India, Japan, Israel and several other countries all regularly obtain private user data from Google. The company will insist on a court order for some kinds of user data, but will disclose many other types of data and subscriber records without first insisting on an order issued by an independent judge. This isn't because Google is evil, but because privacy laws in these countries, the US included, are so weak.

Google does not treat all governments equally though. For example, the company will not honor requests from the governments of Iran, Libya, Zimbabwe, Vietnam and several other countries. You might be inclined to believe that Google has taken this position because of the poor human rights record in these countries - that is part of the reason (but not the whole one, otherwise, Google would refuse requests from the US government which has a documented track record of assassination, rendition/kidnapping and torture). Google's policy of refusing these requests, I believe, largely comes down to the fact that Google does not have an office or staff in those countries. Without a local presence, employees to threaten with arrest or equipment to seize, these governments lack leverage over Google.

This situation is not specific to Google - Facebook, Yahoo, Microsoft and other large US firms all disclose user data to governments that have leverage over them, and ignore requests from others. Thus, lacking any "legitimate" way to engage in what they believe is lawful surveillance of their citizens, these governments that lack leverage have turned to other methods. Specifically, network surveillance.

An unintended consequence of HTTPS by default

When users connect to Facebook, Twitter, or Hotmail—as well as many other popular websites—they are vulnerable to passive network surveillance and active attacks, such as account hijacking. These services are vulnerable because they do not use HTTPS encryption to protect all data as it is transmitted over the Internet.

Such attacks are trivially easy for hackers to perform against users of an open WiFi network using tools like Firesheep. They are also relatively easy for government agencies to perform on a larger scale, when they can compel the assistance of upstream ISPs.

As I described above, because Google will not respond to formal requests for user data from certain governments, it is likely that the state security agencies in these countries have come to depend on network interception, performed with the assistance of domestic ISPs.

Unfortunately for these governments, in January 2010, Google enabled HTTPS by default for Gmail and a few other services. Once the firm flipped the default setting, passive network surveillance became impossible. Thus, in January 2010, the governments of Iran and a few other countries lost their ability to watch the communications of domestic Google users.

For now, these governments can still spy on Facebook, Twitter and Hotmail, as these services do not use HTTPS by default. That is changing though. Following the release of Firesheep in October 2010, (as well as two senior US government officials calling for encryption by default) all three services now offer configuration options to force the use of HTTPS. These firms are all moving towards HTTPS by default - for some firms, it will likely be a matter of weeks until it happens, for others, months.

Governments can see the writing on the wall - HTTPS by default will become the norm. Passive network surveillance will lose its potency as a tool of government monitoring, and once that happens, the state intelligence agencies will "go dark", losing the ability to keep tabs on their citizen's use of foreign, mostly US-based Internet communications services.

HTTPS Certificate Authorities and surveillance

As these large providers switch to HTTPS by default, government agencies will no longer be able to rely on passive network interception. By switching to active interception attacks, these governments can, in many cases, easily neutralize the HTTPS encryption, thus restoring their ability to spy on their citizens. One active attack, known as a "man in the middle attack" requires that the government first obtain a HTTPS certificate issued by a Certificate Authority (CA) trusted by the major web browsers.

In March of 2010, Sid Stamm and I published a paper on what we called compelled certificate creation attacks, in which a government simply requires a domestic Certificate Authority issue it one or more certificates for surveillance purposes. When we released a draft of our paper, we also published a product brochure I had obtained in the fall of 2009 at the ISS surveillance conference, for a Packet Forensics interception device that described how it could be used to intercept communications using these kinds of certificates.

The browsers trust a lot of Certificate Authorities, probably too many. These include companies located in countries around the world. They also include Certificate Authorities that are operated by government agencies. For example, Microsoft trusts a couple dozen governments, that include Tunisia and Venezuela. It is perhaps worth noting that Microsoft continues to trust the Tunisian government even after it was caught in December 2010 actively hijacking the accounts of Facebook users -- an act that led to Facebook enabling HTTPS by default for all users in the country.)

In any case, as Sid an I described, governments can compel domestic Certificate Authorities to provide them with the certificates necessary to intercept their own citizens' communications. However, not all governments around the world are as lucky as Tunisia to be trusted by the browsers, nor do all of them have a domestic certificate authority that they can bully around. Some countries, like Iran, have no way to obtain a certificate that will let them spy on Google users (yes, I know that you can buy intermediate CA issuing powers, but I am assuming that no one will sell this to the Iranian gov).

In recent weeks, we have learned that the encrypted communications of 300,000 people in Iran were monitored by an entity using a certificate that DigiNotar issued. While the Iranian government has not admitted to conducting this man in the middle surveillance against its citizens, it seems reasonable to assume they were behind it. The reason for this certificate theft seems pretty clear, when you consider the other details described in this blog post:

Iran wants to spy on its citizens. It wants the same interception and spying capabilities that the US and other western governments have. Unfortunately for the Iranian government, it has no domestic CA, and Google doesn't have an office in Tehran. So, it used a certificate obtained by hacking into a CA already trusted by the browsers - a CA that had weak default passwords, and that covered up the attack for weeks after it learned about it, giving the Iranian government plenty of time to use the stolen certificate to spy on its citizens.

As Facebook, Twitter and other big sites embrace HTTPS by default, the temptation will grow for for governments without other ways to spy their citizens to hack into certificate authorities with weak security. Can you blame them?

NSA and other US government agencies have gambled with our security

In December 2009, after I had obtained Packet Forensics' product marketing materials, I met with a former senior US intelligence official. I told him that I believed that governments around the world were abusing this flaw to spy on their own citizens, as well as foreigners. When I told him I would be going public in a few months, motivated by my concerns about China and other governments spying on Americans, he said I would be aiding "terrorists in Peshawar" by helping to secure their communications. Needless to say, our meeting wasn't particularly productive.

US intelligence agencies have long known about the flaws associated with the current certificate authority web of trust. For example, in 1998, James Hayes, an air force captain working for the National Security Agency published an academic paper in which he described the ease with which certificates could be used to intercept traffic:

Certificate masquerading allows a masquerader to substitute an unsuspecting server’s valid certificate with the masquerader’s valid certificate. The masquerader could monitor Web traffic, picking up unsuspecting victims’ surfing habits, such as the various net shopping malls and stores a victim may visit. The masquerader could change messages at will without detection, or collect the necessary information and go shopping on his or her own time.

Of course, it isn't too surprising that NSA has known about these vulnerabilities. If the agency hadn't know about these risks, it would have been grossly incompetent.

The question to consider then, is what has and hasn't the NSA done with this knowledge. In addition to attacking the computers of foreign governments, NSA is supposed to protect US government electronic assets. In the 10 years since NSA first acknowledged it knew about the problems with certificate authorities, what steps has the agency taken to protect US government computers from these attacks? Likewise, what has it done to protect US businesses and individuals?

The answer, I believe, is "nothing". The reason for this, I suspect, is that NSA wanted to exploit the flaws itself and didn't want to do anything that would lead to the elimination of what is likely a valuable source of intelligence information -- even though this meant that the governments of China, Turkey, Israel, Tunisia and Venezuela would have access to this surveillance method too.

Perhaps this was a reasonable choice to make, when the intelligence agencies abusing the flaw could be trusted to do so discreetly (The first rule of State-run CA Club is...). The Iranians have upset that delicate understanding. They have acquired and used certificates in a manner that is anything but discreet, thus forcing the issue to the front page of newspapers around the world.

Now, any state actor or criminal enterprise with a budget to hire hackers can likely get its hands on fraudulent certificates sufficient to intercept users' communications, as Comodo and DigiNotar will not be the last certificate authorities with weak security to be hacked. Hundreds of millions of computers around the world remain vulnerable to this attack, and will likely stay this way, until the web browser vendors decide upon and deploy effective defenses.

Had the US defense and intelligence community acted 10 years ago to protect the Internet, instead of exploiting this flaw, we would not be in the dire situation that we are currently in, waiting for the next hacked certificate authority, or the next man in the middle attack.

Warrantless "emergency" surveillance of Internet communications by DOJ up 400%

noreply@blogger.com (Christopher Soghoian) — Thu, 04 Aug 2011 17:20:00 +0000

According to an official DOJ report, the use of "emergency", warrantless requests to ISPs for customer communications content has skyrocketed over 400% in a single year.

The 2009 report (pdf), which I recently obtained via a Freedom of Information Act request (it took DOJ 11 months (pdf) to give me the two-page report), reveals that law enforcement agencies within the Department of Justice sought and obtained communications content for 91 accounts. This number is a significant increase over previous years: 17 accounts in 2008 (pdf), 9 accounts in 2007 (pdf), and 17 accounts in 2006 (pdf).

Background

When Congress passed the Electronic Communications Privacy Act in 1986, it permitted law enforcement agencies to obtain stored communications and customer records in emergencies without the need for a court order.

In such scenarios, a carrier can (but is not required to) disclose the requested information if it, "in good faith, believes that an emergency involving danger of death or serious physical injury to any person requires disclosure without delay of communications relating to the emergency." Typically, belief means that a police officer states that an emergency exists.

With the passage of the USA PATRIOT Improvement and Reauthorization Act of 2005, Congress created specific statistical reporting requirements for the voluntary disclosure of the contents of subscriber communications in emergency situations. In describing his motivation for introducing the requirement, Senator Lungren stated that:

"I felt that some accountability is necessary to ensure that this authority is not being abused… This information [contained in the reports] I believe should be highly beneficial to the Committee, fulfilling our oversight responsibility in the future … this is the best way for us to have a ready manner of looking at this particular section. In the hearings that we had, I found no basis for claiming that there has been abuse of this section. I don't believe on its face it is an abusive section. But I do believe that it could be subject to abuse in the future and, therefore, this allows us as Members of Congress to have an ability to track this on a regular basis."

The current reports are deeply flawed

The emergency request reports are compiled and submitted by the Attorney General, and only apply to disclosures made to law enforcement agencies within the Department of Justice. As such, there are no statistics for emergency disclosures made to other federal law enforcement agencies, such as the Secret Service, as well as those made to state and local law enforcement agencies.

Furthermore, although 18 USC 2702 permits both the disclosure of the content of communications, as well as non-content records associated with subscribers and their communications (such as geo-location data), Congress only required that statistics be compiled for the disclosure of communications content. It is not clear why Congress limited the reports in this way.

Because the reporting requirements do not apply to disclosures made to law enforcement agencies outside the Department of Justice, and do not include the disclosure of non-content communications data and other subscriber records, the reports reveal a very limited portion of the scale of voluntary disclosures to law enforcement agencies.

Likewise, although Congress intended for these reports to assist with public oversight of the emergency disclosure authority, the Department of Justice has not proactively made these reports available to the general public. The reports for 2006 and 2007 were leaked to me by a friend with contacts on the Hill. I obtained the 2008 and 2009 reports via FOIA requests -- and disgracefully, it took DOJ 11 months to provide me with a copy of the 2-page report for 2009.

The emergency requests documented in these reports only scratch the surface

A letter (pdf) submitted by Verizon to Congressional committees in 2007 revealed that the company had received 25,000 emergency requests during the previous year. Of these 25,000 emergency requests, just 300 requests were from federal law enforcement agencies. In contrast, the reports submitted to Congress by the Attorney General reveal less than 20 disclosures for that year. Even though no other service provider has disclosed similar numbers regarding emergency disclosures, it is quite clear that the Department of Justice statistics are not adequately reporting the scale of this form of surveillance. In fact, they underreport these disclosures by several orders of magnitude.

The current reporting law is largely useless. It does not apply to state and local law enforcement agencies, who make tens of thousands of warrantless requests to ISPs each year. It does not apply to federal law enforcement agencies outside DOJ, such as the Secret Service. Finally, it does not apply to emergency disclosures of non-content information, such as geo-location data, subscriber information (such as name and address), or IP addresses used.

As such, Congress currently has no idea how many warrantless requests are made to ISPs each year. How can it hope to make sane policy in this area, when it has no useful data?

Privacy preserving FOIA lawsuits

noreply@blogger.com (Christopher Soghoian) — Fri, 24 Jun 2011 09:45:00 +0000

Several weeks ago, after an extremely successful online fundraising effort to cover the costs, I filed a FOIA complaint in Washington, DC Federal District Court.

Before filing the complaint, I looked through the court website and paid particular attention to a document posted there, titled Information for Parties Who Wish to File a Civil Complaint (pdf), which states:

The name of this Court must be written at the top of the first page [of the complaint]. The complete name and address for each plaintiff must be included in the caption of the complaint. A Post Office Box is insufficient as an address, unless you file a separate motion asking the Court to permit such an address.

Since moving to Washington DC, I've tried to keep my residential address out of databases, primarily by using a PO Box for everything possible. As such, I wasn't too keen on my home address showing up in a public court docket. Following the guidance given by the court, I put my PO box address on my FOIA complaint and filed an accompanying Motion To Include PO Box Address on Complaint.

Two weeks later, I called the court clerk to find out the status of the case, I was told that my motion had been rejected and that the my complaint and all the accompanying documents had been sent back to me.

The clerk didn't actually tell me the reason why the motion had been rejected, and so as soon as I returned to DC, I refiled the complaint with my home address, which was promptly docketed by the clerk.

Several days later, an envelope from the clerk arrived in the mail, which included a copy of the motion that I had filed. Written on it was a note by Judge Royce Lamberth, informing me that my motion was denied, but that the court would reconsider it if I provided my residence address to be filed under seal for the court and defendants.

This news came too late for me -- my home address is now in the DC court docket (something I am still rather upset about), but perhaps this information will be useful to others.

Motion for Po Box Denied

Senators hint at DOJ's secret reinterpretation and use of Section 215 of the Patriot Act

noreply@blogger.com (Christopher Soghoian) — Wed, 25 May 2011 03:23:00 +0000

Summary

According to two Democratic Senators, the Department of Justice has secretly reinterpreted a controversial provision contained in the USA Patriot Act to give the government surveillance powers that are "inconsistent with the public’s understanding of these laws." The senators also accuse DOJ of misleading the American public when describing the use of this legal authority.

This disclosure builds on previous cryptic statements from DOJ officials regarding the use of "Section 215" powers for "sensitive collection program," and Senator Russ Feingold regarding repeated abuses of Section 215 that he was not permitted to publicly describe.

Although FBI Director Robert Mueller revealed earlier this year that the FBI has used Section 215 powers to monitor the sale of hydrogen peroxide, such data collection is unlikely to be the "sensitive collection program" about which several senators have tried to alert the public.

If I had to make a wild guess, I suspect it is likely related to warrantless, massive scale collection of geo-location information from cellular phones.

Secret reinterpretations of the law

Marcy Wheeler reported this evening that Senators Wyden and Udall, both of whom are on the Intelligence committee have submitted an amendment (pdf) as part of the rushed, bipartisan effort to reauthorize Patriot Act. The amendment is noteworthy not because of the changes to the law it proposes, but the information it reveals:

(6) United States Government officials should not secretly reinterpret public laws and statutes in a manner that is inconsistent with the public’s understanding of these laws, and should not describe the execution of these laws in a way that misinforms or misleads the public;

(7) On February 2, 2011, the congressional intelligence committees received a secret report from the Attorney General and the Director of National Intelligence that has been publicly described as pertaining to intelligence collection authorities that are subject to expiration under section 224 of the USA PATRIOT Act (Public Law 107–56; 115 Stat. 295); and

(8) while it is entirely appropriate for particular intelligence collection techniques to be kept secret, the laws that authorize such techniques, and the United States Government’s official interpretation of these laws, should not be kept secret but should instead be transparent to the public, so that these laws can be the subject of informed public debate and consideration.

For those of you who don't read legalese, this means that the Department of Justice has secretly reinterpreted a controversial provision in the Patriot Act, likely Section 215, and is using it in a way that is inconsistent with the public's understanding of the law.

DOJ has already admitted that Section 215 is being used for a "sensitive collection program"

On September 22, 2009, Todd Hinnen, then the Deputy Assistant Attorney General for law and policy in DOJ’s National Security Division testified before the House Judiciary Subcommittee on the Constitution, Civil Rights, and Civil Liberties in support of the reauthorization of key provisions of the USA PATRIOT Act.

During his oral testimony, Mr. Hinnen stated that:

"The business records provision [Section 215] allows the government to obtain any tangible thing it demonstrates to the FISA court is relevant to a counterterrorism or counterintelligence investigation.

This provision is used to obtain critical information from the businesses unwittingly used by terrorists in their travel, plotting, preparation for, communication regarding, and execution of attacks.

It also supports an important, sensitive collection program about which many members of the subcommittee or their staffs have been briefed."

Section 215 has been repeatedly abused

On October 1, 2009, Senator Feingold made several statements regarding abuses of Section 215 during a Senate Judiciary Committee markup hearing:

"I remain concerned that critical information about the implementation of the Patriot Act remains classified. Information that I believe, would have a significant impact on the debate..... There is also information about the use of Section 215 orders that I believe Congress and the American People deserve to know. It is unfortunate that we cannot discuss this information today.

…

Mr Chairman, I am also a member of the intelligence Committee. I recall during the debate in 2005 that proponents of Section 215 argued that these authorities had never been misused. They cannot make that statement now. They have been misused. I cannot elaborate here. But I recommend that my colleagues seek more information in a classified setting.

…

I want to specifically disagree with Senator Kyle's statement that just the fact that there haven't been abuses of the other provisions which are Sunsetted. That is not my view of Section 215. I believe section 215 has been misused as well."

Likewise, after the Senate rejected several reforms of Section 215 powers in 2009, Senator Durbin told his colleagues that:

"[T]he real reason for resisting this obvious, common-sense modification of Section 215 is unfortunately cloaked in secrecy. Some day that cloak will be lifted, and future generations will whether ask our actions today meet the test of a democratic society: transparency, accountability, and fidelity to the rule of law and our Constitution."

Conclusion

Clearly, there are many unanswered questions - we do not know what kind of data collection is occurring, and why it is problematic enough to cause four senators to speak up publicly. However, given that four senators have now spoken up, this strongly suggests that there is something seriously rotten going on.

Industry-created "privacy enhancing" abandonware

noreply@blogger.com (Christopher Soghoian) — Tue, 03 May 2011 15:55:00 +0000

Industry loves self regulation and why shouldn't it? Given the choice between strong enforcement by a federal agency, and scout's honor promises, industry would be foolish to support a strong FTC.

Unfortunately, the self-regulatory groups and organizations that are created in response to the threat of regulation are often extremely short lived.

Pam Dixon noted this in her her comment (pdf) submitted in response to the FTC's recent privacy report:

[I]ndustry knows that the Commission’s attention span is limited. When the Commission showed interest in online privacy in the years before 2000, industry responded by developing and loudly trumpeting a host of privacy self-regulatory activities. Most of these activities were strictly for the purpose of convincing policy makers at the Commission and elsewhere that regulation or legislation was a bad idea. All of these activities actually or effectively disappeared as soon as new appointees to the Commission demonstrated a lack of interest in regulatory or legislative approaches to privacy.

[These include:]

The Individual Reference Services Group (IRSG) was announced in 1997 as a self-regulatory organization for companies that provide information that identifies or locates individuals. The group terminated in 2001.

The Privacy Leadership Initiative began in 2000 to promote self regulation and to support privacy educational activities for business and for consumers. The organization lasted about two years.

The Online Privacy Alliance began in 1998 with an interest in promoting industry self regulation for privacy. OPA’s last reported activity appears to have taken place in 2001, although its website continues to exist and shows signs of an update in 2011.

The Network Advertising Initiative had its origins in 1999, when the Federal Trade Commission showed interest in the privacy effects of online behavioral targeting. By 2003, when FTC interest in privacy regulation had evaporated, the NAI had only two members. Enforcement and audit activity lapsed as well. NAI did nothing to fulfill its promises or keep its standards up to date with current technology until 2008, when FTC interest increased

Industry created privacy enhancing software is made for regulators, not consumers

A few weeks ago, Ryan Singel at Wired wrote about Google's curious lack of support for Do Not Track (DNT). Rather than embracing the DNT header supported by the three other major browser vendors, Google is instead pushing the 3rd party browser plugins it has released that make it possible for consumers to retain their opt out cookies.

As I told Ryan then:

"[Google's] opt-out cookies and their plug-in are not aimed at consumers," Soghoian says. "They are aimed at policy makers. Their purpose is to give them something to talk about when they get called in front of Congress. No one is using this plug-in and they don’t expect anyone to use it."

Soon after this piece was published, I received a bit of pushback from several friends in Washington, who felt I was unfairly slamming the company.

However, when you actually examine the history of the industry's privacy enhancing technologies, they seem awfully similar to the short-lived self regulatory organizations that Pam Dixon highlighted.

Privacy enhancing abandonware

On March 11, 2009, Google entered the behavioral advertising market. On the same day, Google released its Advertising Cookie Opt-out Plugin for Firefox and Internet Explorer. The browser plugin permanently saves the DoubleClick opt-out cookie, enabling users to retain their opt-out status even after clearing all cookies.

Google's tool was a genuine innovation in privacy enhancing technologies. Furthermore, as the tool was released under an open source license, I was able to take the source code, expand it, and turn it into TACO, which opted consumers out of dozens of different ad networks.

The initial release of Google's plugin worked with Firefox 1.5 through 3.0.

In June 2009, Mozilla released Firefox 3.5. It took Google nearly two weeks to release an update to its plugin that was compatible with the new version of the browser.

One year later, Mozilla released Firefox 3.6 in January 2010. This time, it took more than a month for Google to release an updated version of the add-on.

Most recently, on March 22, 2011, Mozilla released Firefox 4.0. More than 5 weeks later, Google still has not released an updated version of its opt out add-on.

Google can perhaps be forgiven for ignoring the users of its Firefox privacy add-on -- the company's attention seems to have shifted to its new plugin: Keep My Opt Outs, which only supports the company's Chrome Browser (the tool was ~~quickly rushed out~~ announced on the same day that Mozilla announced its support for Do Not Track).

Similarly, in November 2009, the Network Advertising Initiative (an organization representing many of the major ad networks) released its own Firefox plugin that makes opt out cookies permanent. NAI Executive Director Charles Curran told one journalist that "this [tool] has been a recognition of criticism of opt-outs that are recorded in cookies. It's essentially designed to prevent the standard sweep of cookies that you get from a cookie cache dump...It's designed to work with the browser functionality."

As with Google's plugin, although it has been more than 5 weeks since the the release of Firefox 4.0, the NAI plugin still has not been updated to support it.

Why updates are important

When a user upgrades to a new version of Firefox, the browser will check for available updates to all installed browser plugins. Any plugins that have not been updated to support the new browser release will be disabled. This is obviously a pretty big problem, which is why Mozilla actively encourages developers to make sure that their addons support upcoming versions of the browser. For the 4.0 version of Firefox, which was released in March, Mozilla started harassing add-on developers as far back as November, 2010.

As such, there are likely tens of thousands (if not more) users of Firefox 4.0 whose Advertising Cookie Opt-out Plugin is currently disabled due to incompatibility. The moment these users clear their cookies (something some many have configured to happen automatically when they restart their browser), they will lose their doubleclick.net behavioral advertising opt out cookie. Likewise, the thousands of Firefox 4.0 users who had previously installed the NAI opt out plugin have now lost the opt out cookie persistence that they were promised.

These firms have created privacy enhancing technologies and then loudly advertised them to consumers and regulators. Unfortunately, now that the attention of regulators has shifted to Do Not Track, both Google and the NAI appear to have abandoned the users of their respective plugins. Neither firm has provided their users with sufficient notice to let them know the impact, or let them know what other options they have to continue to maintain their opt out choices.

Perhaps the FTC will take notice?