Hi folks,
Micah and I did a session teaching people about Snowflake a few weeks back, and here are the notes that I wrote up for ourselves going into that session, in case they are useful to anybody in the future.
(It was more of a decentralized peer-to-peer session so we don't have anything so organized as a slide deck.)
It's separated into five main sections, with the goal that you can adapt how much time you spend on each section depending on the audience.
Snowflake topics, 2023-05-15:
(1) History and architecture
Born out of the Flashproxy idea (PETS 2012), but Flashproxy didn't do nat piercing and didn't do webrtc
<describe intuition around design>
The basic idea is to handle DPI attacks by looking enough like WebRTC, and to handle IP enumeration attacks by having so many diverse and changing addresses that blocking them all is pointless.
Started with Serene Han's OTF fellowship, then leaped forward again when we made an anti-censorship team and had Cecylia on it
multiple components (more client interactions, more surface area for problems) - stun server for client to learn about connection info - domain front to reach broker - webrtc channel to volunteer proxy
early engineering tradeoff: go-pion vs chrome's libwebrtc
prateek at princeton wrote a short paper guessing some distinguishers that attackers could use. some of them turned out to be good guesses!
used to use azure for the domain front, now use fastly
Scaling to multiple snowflake back-end servers one in sweden one at umich now pushing >25terabytes/day of traffic
(2) Real-world events
- Russia censorship in Dec 2021 - spike in users, but block by webrtc DPI - Iran censorship in Oct 2022 - spike in users, but block by domain front https - #1 app in google play store, and also #2 app, for that day - China, works but sometimes quite slow - packet loss over the GFW leads to poor webrtc performance?
ooni tests for snowflake, showing it working in most places including china
(3) Ways to be a Snowflake volunteer
- browser extension for Firefox, Chrome - and edge now? - headless go proxy for server people - Orbot has a 'kindness mode' - Brave ships the extension as of January - Mullvad considering something similar
NAT piercing, kinds of volunteers
100k volunteers but the vast majority of them are the less useful kind
gamifying the snowflake badge
(4) developer side
iptproxy wrapper in-process library for ios and android
The Orbot 17.0 prerelease offers a better experience, since it is the first Orbot version to use snowflake-02 https://github.com/guardianproject/orbot/releases/tag/17.0.0-RC-1-tor.0.4.7....
reliability layers: - turbotunnel - conflux - striping over multiple snowflakes
data channel vs media webrtc channel -- impacts both realism and reliability
domain fronting isn't the only signaling channel we could use orbot ships with google amp cache as an alternative channel we could also use dnstt or other ideas in the future
surprises, e.g. people in censored countries becoming snowflake volunteers
(5) future work, funding, community
Reusing our Snowflake volunteer pool for other projects? Too risky because whichever project draws the most attention blocks the snowflake pool for everybody else Besides, you really (should) want the distributed-trust features of Tor, to keep your users and your Snowflakes safe.
how to handle enumeration attacks on the broker? tension between really simple broker and handling more attacks
future work: realistic behavior layer a la Raven
future work: better user counting We currently suffer from the same user (under)counting issues as Tor
Funding groups to run Snowflake volunteers? part of otf rapid response plan for iran, short term maybe future plans to fund groups too? but centralizing our snowflakes kind of defeats the point
Other ideas for growing the community, e.g. integrating Snowflake into your project