serene

concert pianist / technologist / etc.

On Internet Freedom

a long overdue note
serene | march 2022 | 3min read

The reason I'm writing this is to shed some light on a little project I quietly created many years ago, but which has come into greater use lately.

I am the original creator of "snowflake".

The internet has become the infrastructure of our reality.
If this infrastructure is compromised, so too is our reality.

Originally a conceptual exploration & research project, years later this project has taken on a central role in censorship circumvention via the Tor Project as the first use-case, with direct application in the ongoing Ukraine & Russia crisis, and all around the world. As you can see, censorship did ramp up significantly in December 2021, and early 2022, with a corresponding surge in snowflake users.

If you click "enable" above, you'll be able to share your internet connection with someone who is struggling to access the free and open internet.

As long as you leave this browser tab open, with snowflake enabled, someone out there in need will have access to the internet.

If you don't want to keep this tab open, there are other methods to help the internet: including installing the browser extension, or running a cli, or standalone snowflake . These all function the same -- when active, you are contributing your internet connection to the pool of ephemeral proxy volunteers, to help keep the internet free.

If you are a person in need of access to the free & open internet, snowflake has been built-in with the Tor Browser since 2016.

why i built snowflake

All around the world, the internet is filtered, blocked, and manipulated. This is bad.

When the internet is compromised, not only will you be unable to reliably communicate with friends, family, and the world, your reality itself will be compromised. Yours & many people's understanding of what is happening will undoubtedly be distorted in many ways, and your mind itself will come under assault by the infowar, as we've all seen happen throughout the last few years, pandemic and epistemic collapse ad accelerando. And, everybody shall live in fear, confusion, and violence, as the world splinters and spirals downwards whilst x-risks increase.

People will die. People already have.

But we can still do something about it.

In a way, the early internet saved me -- pre social media, pre everything, a story for another time, but I knew the internet was at risk even then, while still a 9 year old teaching myself to code, or finding rare classical recordings, online. I began actively working on internet freedom since 2012, and made a few attempts to cause real things to happen, both during my time at Google, then as a senior research fellow at UC berkeley, and helping the Tor project.

how does it work?

I've already written much on this: including the original documentation and technical overview, which has since been mirrored and kept up-to-date by colleagues at the tor project snowflake wiki .

tldr; It uses webrtc peer-to-peer connections to create very hard to block ephemeral proxies. [1]

  1. Volunteers visit websites which host the "Snowflake Proxy".
  2. Tor clients automatically find available browser proxies over the domain fronted signaling channel (Broker).
  3. Tor Snowflake client and Browser's Snowflake Proxy establish a WebRTC peer connection.
  4. Proxy connects to some relay.
  5. Tor occurs.

This is enough to cause it to be one of the few actually functional circumvention methods & channels of communications currently in use in the ongoing crisis.

So now, instead of re-writing documentation, I can share the story of how I came to be the snowflake mother.

the story of how I built it

A long time ago, in a galaxy far far away (and before I was even legal ;)) I was the first engineer at a place called Google Ideas. At the time, Ideas was a fledgling organization, a thinktank with the honorable goal of "using technology to help those threatened by conflict, instability, and repression" , but without much in the way of headcount or resources. One of the earliest efforts was a project called uProxy which was an early experiment in using webrtc for circumvention, via temporary proxies -- but using Hangouts for rendezvous, because Google.

With a very unrealistic deadline of 2 weeks, I was required to build and live demo uProxy at the "Google Ideas Summit" in NYC. I pulled a few all nighters and built it. It worked.
And the live tech demo was a success.

On that basis, Google Ideas gained much traction and an initial 10+ headcount. And so I helped build and grow the engineering team of Google Ideas along with some amazing colleagues at the time. Of course, despite being a more experienced coder than engineers even a decade+ older than me, being a young lady, credit for my work went to the nearest man.

So I left. [2]

Meanwhile, I was off starting my career as a concert pianist . Going on adventures, playing concertos with orchestras around the world, writing opera for kanye west. Many interesting experiences.

I also picked up a research fellowship with OTF to continue my work. [3]

Since I was at the time now the person in the world most familiar with using WebRTC for circumvention, maybe I could help birth the true form of this tool and help colleagues at Tor with a next generation pluggable transport. [4]

This needed to be written in golang... However, at the time there was no such thing as WebRTC for golang.

So I wrote the first golang webrtc library. [5]

With that out of the way, now I could actually build the thing. The tor client part would be built to the ptspec, which went fairly quickly once the WebRTC golang lib was in order, and the ephemeral proxy part I'd write in parallel for the browser environment. [6]

Meanwhile I had to give the thing a name. I named it "Snowflake" partly as an obvious meta-trolling and intentional namespace collision given the nature of some parts of communications and internet culture during this time period, but also mainly because "ICE" negotiation is an integral part of the rendezvous.

Then I brought it to the tor dev meeting in valencia, and did a live demo of the first snowflake. It worked. Here's my initial mailing to the tor list. [7]

Then, some other dudes announced Snowflake on twitter before I, the author, could, stealing my thunder -- and then other life stuff happened. These things happen, but the important thing was I was able to birth Snowflake, it functions, it has traction, and people are using it and it seems to help them. So I decided to focus just on piano for a while, which worked out great, and I went on tour, got endorsed by Bosendorfer, etc etc.

Since then, many other tor developers have taken on the Snowflake baton, and made fantastic progress, and I am very pleased. It's wonderful that we've been able to gift this next generation circumvention tool to the community, which is currently having real world effects. Of course, the work never ends, and if folks want me to return, it's possible. I have ideas. They should ask me nicely :) Which brings us to:

the future of snowflake

Indeed, it looks like there is much more work to be done. There are currently limitations in the set of snowflake bridges, there are limitations in bandwidth, there are limited resources for the system, and for the developers at Tor and otherwise who could help. On the individual level we can all contribute by adding more snowflake proxies. But there is much to be done on the rendezvous and brokering...

And, for instance, multiplexing. In addition, a more robust and resilient system could potentially happen by integrating with other infrastructure, like satellite internet.

The Snowflake system is still but a tiny fraction of what it could potentially be, and accomplish for internet freedom, and therefore the future of civilization.

The internet has become the infrastructure of our reality.
If this infrastructure is compromised, so too is our reality.

Anyways, I now have to go practice for a benefit concert for peace in Ukraine. Thanks for reading. Feel free to contact me at serene [at] snowstorm [dot] net, or twitter , and other places...

footnotes

  1. The WebRTC handshake is passed through a rendezvous similar to meek, but since the actual traffic goes through the peer-to-peer connection, snowflake benefits from this scalability instead of everything going through domain fronting. It also automates the connection negotiation and NAT traversal so that it's much easier to use than other methods. (No manual port forwarding bs)

  1. I was both the first engineer, and the first to leave Google Ideas. Since then, Google killed uproxy, killed hangouts, killed a whole bunch of other projects, decided to call itself Alphabet, and Google Ideas was rebranded to "Jigsaw".

  1. As an OTF (Open Tech Fund) information controls senior fellow, with the sponsorship of UC Berkeley's ICSI, I was able to continue my work in trying to help the internet stay free.

  1. Pluggable transport -- meaning a method of circumvention you can plug into the existing system in case it's blocked. There was another early pluggable transport called "flashproxy" which was an attempt to use the ephemeral volunteer proxy strategy, but using simple websockets. It was useful back then, but with significant limitations, and has since been deprecated in favor of snowflake. We knew it was necessary to use a more sophisticated method down the road, given the cat and mouse game of censorship circumvention. So, flashproxy is one of the spiritual predecessors, and one could say that uProxy and flashproxy are the ancestors of snowflake.

  1. I took the native webrtc library and applied some linker black magic with cgo bindings to create a way for golang to talk webrtc. (Since then people have made more actual implementation of golang webrtc, thank you, but this initial method got the job done very quickly, using the native lib.) Most of this happened on a highly caffeinated flight. Here's go-webrtc on my github .

  1. To apply the webrtc constructs to the pluggable transport spec was pretty straightforward,, along with the client-side snowflake, which I wrote in coffeescript (even though a lot of people hate coffeescript now, haha). It didn't bother me at the time, and was actually very quick and enjoyable to work in. It got the job done and the value proposition for coffeescript was better at the time, though ecma has come a long way though now years later...

  1. A huge thanks to David (flashproxy) and Arlo for helping code and push together on snowflake since the early days, and Cecylia for taking it to the next level.

return to writings

Last Update: 2023.04.20 | Thoughts my own. | © 2013 - 2023 SERENE