Bad Decisions: Google Screws Over Tools Evading Internet Censorship Regimes

from the who's-fronting-now? dept

Just as places like Russia are getting more aggressive with companies like Google and Amazon in seeking to stop online communications they can't monitor, Google made a move that really fucked over a ton of people who rely on anti-censorship tools. For years, various anti-censorship tools from Tor to GreatFire to Signal have made use of "domain fronting." That's a process by which services could get around censorship by effectively appearing to send traffic via large companies' sites, such as Google's. The link above describes the process as follows:

Domain fronting works at the application layer, using HTTPS, to communicate with a forbidden host while appearing to communicate with some other host, permitted by the censor. The key idea is the use of different domain names at different layers of communication. One domain appears on the “outside” of an HTTPS request—in the DNS request and TLS Server Name Indication—while another domain appears on the “inside”—in the HTTP Host header, invisible to the censor under HTTPS encryption. A censor, unable to distinguish fronted and nonfronted traffic to a domain, must choose between allowing circumvention traffic and blocking the domain entirely, which results in expensive collateral damage. Domain fronting is easy to deploy and use and does not require special cooperation by network intermediaries. We identify a number of hard-to-block web services, such as content delivery networks, that support domain-fronted connections and are useful for censorship circumvention. Domain fronting, in various forms, is now a circumvention workhorse.

In short, because most countries are reluctant to block all of Google, the ability to use Google for domain fronting was incredibly useful in getting around censorship. And now it's gone. Google claims that it never officially supported it, that this was a result of a planned update, and it has no intention of bringing it back:

“Domain fronting has never been a supported feature at Google,” a company representative said, “but until recently it worked because of a quirk of our software stack. We’re constantly evolving our network, and as part of a planned software update, domain fronting no longer works. We don’t have any plans to offer it as a feature.”

As Ars Technica notes, companies like Google may be concerned that it could lead to larger blocks that could harm customers. But, as Access Now points out, there are larger issues at stake, concerning individuals who are put at risk through such censorship:

“As a repository and organizer of the world’s information, Google sees the power of access to knowledge. Likewise, the company understands the many ingenious ways that people evade censors by piggybacking on its networks and services. There’s no ignorance excuse here: Google knows this block will levy immediate, adverse effects on human rights defenders, journalists, and others struggling to reach the open internet,” said Peter Micek, General Counsel at Access Now. “To issue this decision with a shrug of the shoulders, disclaiming responsibility, damages the company’s reputation and further fragments trust online broadly, for the foreseeable future.”

“Google has long claimed to support internet freedom around the world, and in many ways the company has been true to its beliefs. Allowing domain fronting has meant that potentially millions of people have been able to experience a freer internet and enjoy their human rights. We urge Google to remember its commitment to human rights and internet freedom and allow domain fronting to continue,” added Nathan White, Senior Legislative Manager at Access Now.

Google doesn't need to support domain fronting, and there are reasonable business reasons for not doing so. But... there are also strong human rights reasons why the company should reconsider. In the past, Google has taken principled stands on human rights. This is another time that it should seriously consider doing so.

Filed Under: censorship, cloud services, domain fronting, encryption, tor
Companies: google

The Rise Of More Secure Alternatives To Everyone's Favorite Chat App, Slack

from the well-this-could-get-interesting dept

Like a ton of people and companies, we've been using Slack here. While we saw some folks claim it was revolutionary, we found it to be a nice, but somewhat marginal, upgrade to our previous use of Skype chat rooms. But, over time, it has certainly gotten comfortable, and there have been some nice feature add-ons and integrations that have made it a pretty cool service overall -- though if you really want to use it to its fullest extent and switch to the paid version, it can get pretty pricey, pretty quickly. I also am in a bunch of other group Slack chats, as it's basically become the platform of choice for group discussions.

However, in these days where hacked emails are in the headlines, I can see why some might get nervous about using a tool like Slack. Not that there have been any known breaches of Slack that I'm aware of, and I'm sure that the company takes security very seriously (it would undermine its entire business if it failed on that front...), it's been interesting to see other options start to pop up, which might be more appetizing for those who are extra security conscious.

Just as we've been encouraged to see greater use of encryption on mobile phones, email and on websites, it's good to see new entrants trying to take on Slack with a focus on security and privacy. The most recent, and perhaps most interesting, player in the space is SpiderOak, which recently launched its Semaphor Slack competitor on the market. I've been playing around with it -- and while it's early on, it certainly has potential. SpiderOak is the company you should already know of that provides an encrypted "zero knowledge" cloud backup solution. Since you keep the keys, even though it's hosted in the cloud, SpiderOak has no way to decrypt your files should anyone hack in, or should the government come calling. It's now taken that approach to Semaphor, which obviously takes its inspiration from Slack (and feels quite similar), but with the same zero knowledge encrypted setup. You get a key and that encrypts all of the data in your group messaging.

There are some limitations there -- of course -- because any team member might leak their key (though whoever gets in would just have access to whatever that team member can see). And, because of this setup, it's not as easy to do "integrations" with third-party apps and services, which is a key selling point of Slack. Semaphor is apparently trying to work its way around this limitation by creating bots that act as their own users within Semaphor (something Slack has also), but where the bots themselves become the key to integrations. It's a bit more clumsy, but if it helps keep things secure, that seems promising.

SpiderOak also, kindly, makes the Semaphor client source code available for anyone to audit, which is necessary if anyone's going to take their encryption seriously. Of course, Semaphor is, like Slack, working off a Freemium model, where additional features require per user fees, which can add up. One nice feature of Semaphor that Slack doesn't have: the ability for individuals to pay their own way. That is, there are lots of Slack groups that are general interest groups around certain topics, and not a company's own internal group. Those groups are never going to use a paid option, because there's no "company" to pay for all users. Semaphor offers an alternative, where each user can just pay their own way -- which might be appealing to some user groups.

The other alternatives that have been getting some attention lately are a couple of attempts to basically create a truly open source Slack clone that can be self-hosted. The two big players here are Mattermost and RocketChat. Both have built open source, self-hosted Slack clones (and both try to make money by offering paid hosting for those who want it). Mattermost is quite upfront that it's building a Slack alternative -- it's all over its website -- though it also points out that it's tried to improve on some things in Slack. RocketChat doesn't seem to mention Slack, and, frankly, feels a bit behind Mattermost in development (though it also announced that it's about to run a Kickstarter campaign to jumpstart more development.

Now, whether or not a self-hosted open source alternative is more secure than Slack... may depend. If you're doing the self-hosted version then you're basically relying on your own ability to keep the implementation secure. That might work. Or, whoever you have securing your installation might not be as good or as responsive as, say, the security team at Slack. But, using an open source solution that you host obviously does provide you with a lot more control and the ability to make any changes you think are necessary.

As someone who talks quite frequently about how competition drives innovation, it's great to see all of this happening. I don't think any of them will harm Slack's place in the market, which has become pretty standard in a lot of companies, but as more and more companies are realizing that they need to really think through security of their communications tools, it's a very good thing to see competition popping up. Hopefully, these competitors get stronger as well, and help drive more overall innovation -- including the focus on security and encryption -- across the entire market.

Filed Under: chat, cloud services, encryption, messaging, open source, security, work
Companies: mattermost, rocketchat, slack, spideroak