DEV Community: Denis Rybakov

Circumventing Internet Censorship: Protocols, Techniques, and the Arms Race

Denis Rybakov — Sun, 15 Feb 2026 23:21:45 +0000

Part 2 of the series: "Internet Censorship in Russia: A Technical Deep Dive"

Disclaimer

Educational Purpose: This article examines the technical architecture of internet filtering systems for educational purposes. The author does not encourage violation of local laws. All information is based on publicly available sources and open-source research.

Quick Recap: What We Learned in Part 1

In Part 1, we examined Russia's TSPU (Technical Means of Counteracting Threats) infrastructure.

Key points to remember:

What TSPU can do:

See SNI (Server Name Indication) in TLS Client Hello — primary blocking method
Analyze metadata: packet sizes, timing patterns, connection duration
Use ML/statistics to fingerprint VPN protocols
Actively probe suspicious servers
Send RST packets to kill connections

What TSPU cannot do:

Decrypt modern TLS without MITM (Man-in-the-Middle)
Process 100% of traffic deeply (performance constraint at 100 Gbps)
Block without collateral damage (shared IPs, CDN problem)

The fundamental trade-off is usual: performance versus accuracy.

Key insight from Part 1: TSPU has limitations imposed by physics (processing speed) and architecture (distributed internet).

Two Sides of Technical Conflict

To understand circumvention approaches, we need to think from both perspectives:

"Attacker" side (conditional term, not moral judgment):

People wanting access to blocked resources
Privacy enthusiasts
Engineers researching censorship resistance
Goal: exploit architectural weaknesses of filtering infrastructure

"Defender" side (conditional term, not moral judgment):

TSPU operators
Government filtering mandate
Goal: maximize blocking effectiveness within architectural and economic constraints

In this part, we'll "wear shoes" of both sides:

What weakness does attacker exploit?
How can defender adapt?
What is next move in response?

This is engineering analysis of distributed systems under adversarial conditions.

Now we look at how circumvention techniques exploit TSPU limitations. First we recall OSI model to understand where encryption happens. Then we discuss what architectural weaknesses can be exploited.

Understanding Network Layers and Encryption

To understand why specific technique works, it is useful to look at where encryption happens in network stack.

Where encryption operates determines what DPI can see. Despite fact that DPI doesn't rely only on visible data, but also on packet and traffic patterns, visible part is checked first due to simplicity.

OSI Model: Where Things Happen

The OSI model describes network communication in layers:

┌─────────────────────────────────────┐
│ L7: Application (HTTP, SSH)         │
├─────────────────────────────────────┤
│ L6: Presentation                    │
├─────────────────────────────────────┤
│ L5: Session (TLS operates here)     │
├─────────────────────────────────────┤
│ L4: Transport (TCP, UDP)            │
├─────────────────────────────────────┤
│ L3: Network (IP)                    │
├─────────────────────────────────────┤
│ L2: Data Link                       │
├─────────────────────────────────────┤
│ L1: Physical                        │
└─────────────────────────────────────┘

TLS is often mapped to OSI Session/Presentation layers, but in modern TCP/IP model it acts as a security layer between application and transport.

What DPI Sees at Different Layers

Normal HTTPS connection (TLS-encrypted):

┌──────────────────────┐
│ HTTP (L7)            │
├──────────────────────┤
│ TLS (L5)             │ ← Encrypts HTTP
├──────────────────────┤
│ TCP (L4)             │
├──────────────────────┤
│ IP (L3)              │
└──────────────────────┘

What DPI sees:
✅ IP addresses (source, destination)
✅ TCP ports (443 for HTTPS)
✅ TLS handshake (Client Hello, Server Hello)
✅ SNI field in Client Hello ← PLAINTEXT
❌ HTTP content (encrypted by TLS)

The critical point: SNI must be sent before encryption begins (TLS specification requirement). This is primary blocking method in Part 1.

Nested Encryption: Protocol Inside Protocol

Here is interesting property of network stack: upper layer protocols can encapsulate lower layer protocols.

Example: HTTPS inside SSH tunnel

┌──────────────────────┐
│ HTTP (L7)            │
├──────────────────────┤
│ TLS (L5)             │ ← Encrypts HTTP
├──────────────────────┤
│ SSH (L7)             │ ← Encrypts TLS!
├──────────────────────┤
│ TCP (L4)             │
├──────────────────────┤
│ IP (L3)              │
└──────────────────────┘

What DPI sees:
✅ IP addresses
✅ TCP ports
✅ SSH protocol handshake
❌ TLS Client Hello (hidden inside SSH)
❌ SNI (hidden inside SSH)
❌ HTTP content (double-encrypted)

This is called nested encryption or protocol tunneling. We will return to this idea later.

Exploiting TSPU Architectural Weaknesses

Let's recall DPI limitations and specefics from Part 1:

Cannot decrypt encrypted traffic
Must work at line speed (100 Gbps)
Can analyze unencrypted hello-part of TLS

Now we address each limitation and see how "attacker" side can use it.

Weakness 1: Cannot See Inside Encrypted Traffic

Attacker approach: Use transport layer (L4) and build own encryption on top, where all traffic is encrypted.

Example: WireGuard protocol.

Defender response: Two options:

Ban all encrypted non-standard traffic (too broad, breaks legitimate apps)
Learn patterns of encrypted traffic (current approach)

How defender detects WireGuard:

For now, DPI in Russia detects pure WireGuard due to simple traffic patterns — standard size of first segment and reply. This is based on encryption specifics.

Detection logic:

Is it UDP?
Is first packet 148 bytes?
Is second packet 92 bytes?
Are data packets 16-byte aligned?

If all yes → WireGuard detected.

Attacker counter-adaptation: Use noise in protocol to break standard and repeated sizes.

Example: AmneziaWG — WireGuard updated with random padding rules.

What it changes:

1. Packet size randomization:

Normal WireGuard:
[Header: 16 bytes][Payload: 132 bytes] = 148 bytes (fixed!)

AmneziaWG:
[Header: 16 bytes][Payload: 132 bytes][Random padding: 0-100 bytes]
= 148-248 bytes (varies each packet)

2. Junk packet injection:

Send random UDP packets mixed with real WireGuard packets
Real packets have correct structure
Junk packets are random data
Server knows which are real (based on crypto validation)
DPI sees inconsistent packet sizes, garbage mixed with data

3. Protocol constants modification:

User can configure custom values that control padding behavior and junk generation
Different configurations create different fingerprints
Each client-server pair has unique "noise signature"

This is basic idea of how AmneziaWG works.

Vulnerability to government MITM:

AmneziaWG and WireGuard are not vulnerable to CA-based MITM because:

Work at UDP level (no TLS involved)
Implement own crypto (not certificate-based)
Government CA certificates are irrelevant

This is advantage over TLS-based approaches.

Weakness 2: TLS Client Hello Must Be Plaintext

We have TLS that cannot be decoded by DPI after handshake. But Client Hello is plaintext — can attacker still use strong side of TLS (encrypted traffic) while making unencrypted Hello useless for blocking?

The idea (related to nested encryption from OSI section): Deploy specific proxy-server with conditional behavior:

If authorized client → redirect through "white" site, then use encrypted channel as tunnel
If unauthorized client (DPI probe) → just proxy to real "white" site

This way, Client Hello goes to innocent site (passes checks), but encrypted channel carries real traffic.

This idea found implementation in VLESS+Reality protocol.

How VLESS+Reality Works

VLESS+Reality works roughly like this (simplified understanding, not exact implementation):

Architecture:

Reality is proxy server that receives TLS connections and makes decision: "is this my real client or someone else (maybe DPI probe)?"

Decision based on secret marker hidden in Client Hello.

For authorized client (knows the secret):

1. Client initiates TLS to github.com
   Client Hello contains:
   - SNI: github.com ← looks innocent
   - Secret marker in TLS session_id field

2. Reality server receives Client Hello
   - Extracts session_id
   - Checks secret marker
   - If valid → this is authorized client

3. Reality proxies TLS handshake to REAL github.com
   - Connects to actual GitHub servers
   - Gets GitHub's real certificate
   - Sends it to client
   - Client validates (it's real GitHub cert!)

4. TLS handshake completes → encrypted channel established

5. Reality switches connection into VLESS tunnel mode
   - Traffic inside TLS is VLESS protocol
   - VLESS can proxy connections anywhere
   - All hidden inside encrypted channel

For unauthorized client (DPI probe or random person):

1. Client connects without correct secret marker

2. Reality server detects invalid/missing marker
   - Acts as transparent proxy to github.com
   - Passes everything to real GitHub

3. Client talks to actual GitHub
   - Gets real GitHub responses
   - Cannot tell Reality server is involved

Why this design is beautiful:

What TSPU sees in both cases:

Authorized client:

SNI: github.com ✓
Destination IP: GitHub's actual IP ✓
TLS handshake: normal ✓
Certificate: real GitHub certificate ✓
After handshake: encrypted traffic ✓

Unauthorized client (DPI probe):

SNI: github.com ✓
Destination IP: GitHub's actual IP ✓
TLS handshake: normal ✓
Certificate: real GitHub certificate ✓
After handshake: connection to real GitHub ✓

From outside, both look identical!

How TSPU Can Still Detect Reality and how defender adapts:

Despite sophistication, VLESS+Reality has weaknesses:

Statistical patterns: Normal GitHub or other innocent site sessions are short and bursty in common. VPN tunnels are long-lived with continuous bidirectional flow. ML can flag anomalies.

IP reputation: If many clients connect to one IP with "github.com" SNI but IP is in VPS range → suspicious → triggers probing.

Government MITM: In case when user has Ministry root CA installed, government can substitute certificate, decrypt TLS, see VLESS inside. It works like follow:

Normal:
Client → Reality → GitHub → Real cert → Client ✓

With MITM:
Client → [DPI intercepts] → Reality
         ↓
    DPI generates substitute certificate
    Signed by Ministry CA

If client have a Ministry root CA installed, then:
→ Accepts substitute certificate
→ TLS connection is to DPI, not Reality
→ DPI decrypts all traffic
→ Sees VLESS protocol inside
→ Connection blocked or compromised

Weakness 3: DPI operates at line speed

From Part 1 we've learned a TSPU's trade-off of accuracy versus speed.

Defender constraint: Must process packets in microseconds at 100 Gbps.
Attacker exploit: Make analysis expensive enough that DPI cannot keep up.

Example tools: GoodbyeDPI, Zapret.

The Idea: Make analysis expensive enough to slow down a DPI filtering speed. Base idea is to split segments to smaller parts, wich force TSPU to gather a session, add a short-living segments that take a time to analyze but not received by destination - set a proper TTL and other teqniques.

TCP Segmentation

Concept: Split TLS Client Hello across multiple TCP segments so complete data is not visible in single packet.

Normal (one packet):

TCP packet (seq=1000):
┌────────────────────────────────────┐
│ TCP Header | TLS Client Hello      │
│            | SNI: blocked-site.com │
└────────────────────────────────────┘

DPI: sees complete data → fast check → BLOCK

With segmentation (two packets):

Packet 1 (seq=1000):
┌────────────────────────────────────┐
│ TCP Header | TLS partial...        │
│            | SNI: "blocked-si      │ ← incomplete!
└────────────────────────────────────┘

Packet 2 (seq=1050):
┌────────────────────────────────────┐
│ TCP Header | te.com"...            │
└────────────────────────────────────┘

What defender (DPI) must do:

Buffer packet 1 (requires memory)
Wait for packet 2 (requires state tracking)
Reassemble TCP stream (requires CPU)
Extract complete data
Check against blocklist

TTL Manipulation

Concept: Send two copies with different TTL (Time To Live) values. Or send a junk with short-living TTL.

Packet 1 (decoy):
TTL = 5 → expires at DPI node
SNI: "google.com"

Packet 2 (real):
TTL = 64 → reaches destination
SNI: "blocked-site.com"

Logic:
- DPI analyzes packet 1, sees "google.com" → allow
- Packet 1 expires before destination
- Packet 2 arrives, DPI cache says "allowed" → passes
- Destination receives only packet 2

There are some other tricks, that base on the same idea of manipulation of data in frames of allowed OSI stack.

Current effectiveness:

Highly dependent on:

ISP's TSPU configuration
Time of day (better during peak hours when TSPU under load)
Specific blocklist entries (some enforced stricter)

Also, a circumvention software should be often updated to keep up with the changes in TSPU.

What we've learned:

Circumvention is not about "unbreakable" protocol. It's about:

Understanding system's architectural constraints
Finding weakness in constraint
Exploiting it
Adapting when system adapts

What's Next

In Part 3, we'll examine real-world case studies:

YouTube throttling — how selective slowdown works (GGC manipulation)
Roblox complexity — why modern cloud architecture is hard to block (WebRTC, dynamic IPs, collateral damage)
FaceTime blocking — surgical, protocol-specific filtering with minimal collateral damage

We'll also discuss future: whitelisting scenarios, ECH status in Russia, QUIC challenges, and other constraints.

Next in series: Part 3 - "Case Studies: YouTube, Roblox, FaceTime, and what comes next"

Russia's Internet Filtering Infrastructure: Evolution and Architecture

Denis Rybakov — Sat, 07 Feb 2026 11:37:15 +0000

Part 1 of the series: "Internet Censorship in Russia: A Technical Deep Dive"

Disclaimer

Educational Purpose: This article examines the technical architecture of internet filtering systems for educational purposes. The author does not encourage violation of local laws. All information is based on publicly available sources and open-source research.

Introduction: Why This Matters for Engineers

What makes Russia's internet filtering infrastructure technically interesting for us, engineers:

Scale: Distributed real-time system operating at main network speeds
Complexity: Combining networking, cryptography, and ML/staticsics in a single architecture
Evolution: A genuine "arms race" of algorithms, protocols and ideas happening in real-time
Architecture: Lessons applicable to any high-throughput, stateful inspection system

Here we examines the technical aspects from an engineering perspective, without political commentary using Russia as example. There is also another notorious example of such systems: China Great Firewall, and we will make some comparison with this two. We'll look at how they work, what problems they solve, and what trade-offs engineers make. We'll also discuss how circumvention works and what means exist to bypass these systems and how.

A red thread of this topic is that no event or technology should be considered in only present state, we need a historical perspective to understand what is happening now and why some decisions were made.

This isn't a political piece. Here we discuss architecture, engineering problems, trade-offs and solutions on both sides.

Volens-nolens, to understand a topic, we need to look from both perspectives: the filtering and the circumvention sides. Not to pick one, but to understand what tools exist and what decisions engineers make.

Whether you're interested in network security, distributed systems, or privacy-preserving technologies, understanding how modern internet filtering works provides valuable insights.

From IP Blocking to Deep Packet Inspection: The Evolution

The Early Stage: Simple IP Blocking

In the beginning, internet filtering in Russia was primitive—blocking by IP addresses. This worked against small websites with dedicated IPs, but quickly proved ineffective:

Problems with IP blocking:

Collateral damage: A single IP can host thousands of websites (shared hosting, CDN)
- Block one site → accidentally block hundreds of legitimate sites
- Example: Blocking a Cloudflare IP affects 10,000+ domains
Easy circumvention: Change the server's IP address
- Takes 5 minutes to update DNS
- Blocking is always playing catch-up
Cloud infrastructure: Services like Telegram use thousands of IP addresses
- 2018: Attempted Telegram block resulted in ~18 million IPs blocked
- Collateral damage: AWS, Google Cloud services affected
- Telegram remained operational via proxy networks

Example of an IP-based blocking in Russia

In 2018 it was a notorious Telegram blocking attempt. The Russian government blocked ~18 million IP addresses with heavy collateral damage ( Academy of Sciences made a lawsuit against network censorship ministry ) but without any real effect on Telegram.

What happened? AWS services went down for businesses, Google Cloud was
affected, random legitimate websites became unreachable, Sites and services of a Russian Academy of Sciences, some goverment detachments were blocked.
And as icing on a cake: Russia network censoship ministry services was also blocked in process.

In those time it was a big problem for Russian government but for regular users future looks brilliant and cloudless, seems no real censorship possible.

But it was not the end of the story.

The system needed to evolve.

Evolution Path

2012-2015: IP-based blocking
    ↓
2015-2017: DNS filtering
    ↓
2017-2019: SNI inspection (TLS handshake analysis)
    ↓
2019-present: Deep Packet Inspection + Behavioral analysis

What is Deep Packet Inspection (DPI)?

DPI is not just a filter—it's a real-time traffic classification system operating at network backbone speed.

Key characteristics:

Analyzes packet contents, not just headers ( despite of it is impossible to decrypt TSL after hello exchange )
Maintains state across connections (stateful inspection)
Makes decisions in microseconds
Must handle 10-100+ Gbps throughput

This leads to both capabilities and limitations, which we'll explore next.

TSPU: Russia's DPI Infrastructure

What is TSPU?

TSPU (Технические Средства Противодействия Угрозам, "Technical Means of Counteracting Threats") is Russia's DPI-based filtering infrastructure, mandated by the "Sovereign Internet" law of 2019.

Aspects of TSPU in Russia is classified, but we can make a educated guess based on behavior.
Areas in Russia differs by filtering rules, this difference looks like testing of new rules before rollout or some local restrictions. This can lead us to key architecture principles of this system.
Another key insight is a law and a demand to set up TSPU in every ISP in Russia.

Key differences from China's Great Firewall:

Aspect	China (GFW)	Russia (TSPU)
Architecture	Centralized: ~3 major backbone chokepoints	Distributed: Thousands of ISP nodes
Control	Direct government operation	Installed at ISPs, remotely managed
Deployment	Border filtering (international traffic)	Both domestic and international
Transparency	"Black box"	Legal framework with ISP obligations

It's said that distributed architecture means Russia can't simply "flip a switch" to filter all traffic at once and in same time - like China can, but it actually does not matters for users - if a "switch flipped" in Russia it results in a gradual filtering rules implementation, but at the end - result the same.

Deployment Architecture

Where TSPU is installed:

ISP nodes (mandatory for major operators)
- At Internet Service Provider facilities
- Both mobile and fixed-line networks
- Operators legally required to allow installation
Backbone channels
- Major inter-city links
- Internet Exchange Points (IX)
- International gateway connections
Two operational modes:

Active mode (inline filtering):

Internet traffic → TSPU (analyzes & filters) → Destination

All traffic passes through TSPU
Can block or modify packets in real-time
Adds latency (milliseconds)
More effective filtering

Passive mode (monitoring):

Internet traffic → TAP/SPAN port → TSPU (analyzes copy)
                ↓
            Direct flow (unaffected)

Receives copy of traffic for analysis
Can send RST packets to terminate connections
Cannot modify packets in-flight
Lower latency impact

Why two modes?

My understanding: most ISPs run active mode as primary filtering, but use
passive mode as a complement.

_Active mode catches obvious violations in real-time. Passive mode is for
the non-obvious cases — suspicious patterns that need deeper analysis without _ blocking traffic immediately. TSPU need to pass packet if it fails to analize it.

It's like having a bouncer at the door (active) and security cameras
watching for unusual behavior (passive).

Technical Capabilities

What TSPU Can See and Do

1. Unencrypted data visibility:

IP addresses and ports (always visible)
DNS queries
HTTP headers (if not HTTPS)
SNI in TLS Client Hello ← Primary blocking method for HTTPS

Why SNI matters:

TLS Handshake (simplified):

Client → Server: Client Hello
├─ TLS version
├─ Supported ciphers
└─ SNI: "blocked-site.com" ← VISIBLE IN PLAINTEXT

[Rest of handshake encrypted]

The SNI (Server Name Indication) tells the server which domain the client wants to reach. It's transmitted before encryption begins, making it perfect for filtering.

2. Metadata analysis:

Packet sizes and patterns
Intervals between packets
Connection duration
Volume of transferred data
Flow direction: upload vs download ratio

3. Machine Learning classification:

Protocol identification by traffic patterns
VPN service fingerprinting
Behavioral analysis:
- Normal web browsing: burst patterns (page load → pause)
- VPN: continuous bidirectional flow
- Streaming: large download, small upload

4. Active probing:
Here is what TSPU passive mode seems designed for. When TSPU detects suspicious traffic:

1. Client connects to suspicious IP:port
2. TSPU records: IP 1.2.3.4:8443
3. TSPU initiates its own connection to 1.2.3.4:8443
4. Sends typical VPN handshake packets
5. Analyzes server response
6. If server responds like VPN → add to blocklist

This is why running a VPN server on a public IP is increasingly difficult—TSPU will discover and block it automatically.

5. Government certificates:

Ministry of Digital Development root certificates
Enables MITM (Man-in-the-Middle) attacks on TLS
Currently limited deployment (pilot projects)
If widely adopted: could decrypt all HTTPS traffic

Why someone need to install a Goverment root certificate? It is obligatory if we need to connect to some legal services for online service: tax, socials, medicine.

What TSPU Cannot Do

1. Decrypt TLS traffic (without MITM):

Modern TLS with forward secrecy
No way to decrypt past traffic even with keys

2. Inspect encrypted tunnels:

VPN protocols use their own encryption
Cannot see contents of WireGuard, OpenVPN, etc.
Can only analyze metadata and patterns

3. Process 100% of traffic:

The performance constraint: At 100 Gbps backbone speeds, there's
~0.1 microseconds per packet. Deep analysis is physically impossible
for all traffic.

This is why circumvention exists.

TSPU architects know this. They made a conscious trade-off: optimize
for the 80% case (SNI blocking), use sampling for the rest.

This creates opportunities. When TSPU is under load (peak hours, DDoS,
major events), filtering quality degrades. Sophisticated circumvention
techniques slip through.

It's not a bug. It's an inherent limitation of real-time systems at scale.

Here's the fundamental trade-off:

Analysis Depth vs. Coverage:

┌──────────────────────────────────┐
│ Fast check (SNI)                 │ ← 100% of traffic
├──────────────────────────────────┤
│ Statistical analysis             │ ← ~50-70% (sampling)
├──────────────────────────────────┤
│ ML classification                │ ← ~10-20% (expensive)
├──────────────────────────────────┤
│ Deep reconstruction              │ ← <1% (suspicious only)
└──────────────────────────────────┘

The performance constraint: At 100 Gbps backbone speeds, there's ~0.1 microseconds to make a decision per packet. Deep analysis is simply too expensive for all traffic.

4. Block without collateral damage:

Shared IP problem: One IP = hundreds of sites
CDN infrastructure: Cloudflare, AWS, etc.
Blocking Cloudflare IP → hundreds of innocent sites affected

Detection Methods: How TSPU Identifies VPNs

1. Statistical Fingerprinting

VPN traffic has characteristic patterns that differ from normal HTTPS:

Packet size distribution:

Normal HTTPS:
Size: [52, 1460, 1460, 52, 150, 1460, ...]
      Small requests, large responses

VPN:
Size: [148, 92, 1320, 1280, 1350, ...]
      More uniform distribution

Timing analysis:

Normal HTTPS:
Packets: [0ms, 50ms, 51ms, 2000ms, 2050ms, ...]
         Bursts (page load), then pauses

VPN:
Packets: [0ms, 25000ms, 50000ms, 75000ms, ...]
         Regular keepalive packets

Connection characteristics:

Long-lived connections (hours vs minutes)
Balanced bidirectional traffic
Continuous data flow (not a burst)

2. Protocol Signatures

Each VPN protocol has recognizable patterns:

WireGuard:

Handshake Initiation: exactly 148 bytes
Handshake Response: exactly 92 bytes
UDP protocol (not TCP)
Specific packet size alignment (multiples of 16)
pure WG is useless in Russia due to static handshake pattern

OpenVPN:

Characteristic handshake sequence
Currently in Russia this protocol useless for censorship circumventing - outdated and well-known patterns seen by DPI.

Shadowsocks:

Specific SOCKS5 patterns
Currently in Russia this protocol useless for censorship circumventing - it seen by DPI and blocked with ease.

3. Active Probing

TSPU doesn't just passively observe—it actively tests suspicious servers:

Probing workflow:

1. Detect: Suspicious traffic pattern to IP:port
2. Record: Store IP and port
3. Probe: TSPU connects to the same IP:port
4. Test: Send VPN-like handshake packets
5. Analyze: Check if server responds like VPN
6. Block: If confirmed VPN → add to blocklist

This is one of the way how TSPU handle with advanced VLESS+Reality approach.

Why this works:

Most VPN servers respond predictably to handshakes
TSPU can test without being an actual client
Automated discovery of new VPN servers

How VPN protocols defend:

Authentication before responding (VLESS+Reality approach)
Whitelist of allowed client IPs
Respond differently to unauthorized connections

4. Replay Attacks

Concept: Record legitimate traffic and replay it to suspicious servers

But here is not a much information and me personally does not see such behavior, only rumors.

The Fundamental Trade-off

TSPU faces an inherent constraint:

Performance ←→ Accuracy

High throughput processing:
- Fast, simple checks (SNI lookup)
- Low false positives
- Easy to circumvent

Deep analysis:
- Expensive (CPU, memory, latency)
- Better accuracy
- Cannot apply to all traffic

This trade-off is why circumvention is possible. Under load, TSPU must choose between:

Dropping packets (network failure)
Letting suspicious traffic through
Heavy sampling (miss some VPNs)

In peak hours, filtering quality degrades—this is exploitable.

Architectural Challenges

Decentralized Network Problem

Unlike China's centralized Great Firewall, Russia has:

Hundreds of ISPs (not 3-4 major ones)
No single network chokepoint
International connections via multiple routes
Difficulty coordinating across all nodes

Result: Inconsistent filtering across ISPs and regions.

Economic Constraints

Aggressive filtering has costs:

Collateral damage → business complaints
AWS/Cloudflare blocking → economic impact
Performance degradation → legal users and intergoverment exchange have problems
Investment in TSPU infrastructure → budget constraints

The state must balance control vs. economic functionality.

Technical Debt

Modern internet architecture is inherently distributed:

CDN networks (Cloudflare, Akamai, Fastly)
Cloud providers (AWS, Google Cloud, Azure)
Peer-to-peer protocols (WebRTC, BitTorrent)
Dynamic IPs and load balancing

Old model (pre-2010s):

Website → Fixed IP → Easy to block

New model (2020s):

Service → CDN → 10,000 IPs → Shared with other services → Hard to block

Trying to block a single service often requires blocking entire CDN ranges, causing massive collateral damage.

What We've Learned

Key insights about TSPU architecture:

✅ Distributed system operating at massive scale (100+ Gbps)
✅ Real-time classification with microsecond decision windows
✅ Trade-off between depth and coverage (can't deeply analyze all traffic)
✅ Primary method: SNI inspection (simple, fast, effective)
✅ Advanced methods: ML, statistical analysis, active probing
❌ Cannot decrypt modern TLS without MITM
❌ Collateral damage problem with shared infrastructure
❌ Performance constraints limit deep inspection

The bottom line: TSPU is a sophisticated system, but it has fundamental limitations imposed by physics (processing speed), economics (cost vs. benefit), and architecture (distributed internet infrastructure).

What's Next

In Part 2, we'll explore:

How protocols exploit TSPU's weaknesses
The OSI model through a security lens
VPN protocols: WireGuard, VLESS+Reality, Shadowsocks
Packet manipulation techniques (TCP segmentation, TTL tricks)
Why nested encryption (SSH tunneling TLS) works

References & Further Reading

Next in series: Part 2 - "Circumventing Internet Censorship: Protocols, Techniques, and the Arms Race"

[Boost]

Denis Rybakov — Mon, 20 Oct 2025 21:57:53 +0000

Building AI Workflow and Project Context: From Memory Banks to Simple Markdown

Denis Rybakov ・ Oct 20

#ai #productivity #vscode #go

Building AI Workflow and Project Context: From Memory Banks to Simple Markdown

Denis Rybakov — Mon, 20 Oct 2025 19:53:05 +0000

Intro

After experimenting with AI tools like memory-bank, Spec Kit, and Boomerang Tasks, I found that simple .md files for project context and planning often work better.
They keep you in control, preserve project knowledge, and avoid “monstrous” setups that drift away from your actual work.

The Path So Far

This is a short reflection on how I built my AI-assisted workflow — from early code generation experiments to trying to make VSCode as “aware” as Windsurf.

At first, I used AI chat for code generation — no project context, just verbose descriptions and snippets for examples or refactoring.

Then I added AI autocomplete via Continue — still using it.
Next came Claude 4 wrapped in Windsurf, plus the console tool factory.ai and claude code later.
In parallel, I tried a “semi-free” Windsurf setup using VSCode + RooCode — semi, because without a paid backend, you hit the limit quickly: Gemini 2.5 Pro just doesn’t pull it off.

That’s my current baseline setup.

MCP, Context7, and the Memory-Bank Phase

At some point, I heard about MCP and rushed to set up context7, thinking every self-respecting dev already had it running.
Turned out it wasn’t that useful for my particular workflow.

Next came memory-bank — an attempt to preserve project context and bring the VSCode + RooCode setup closer to Windsurf, where it comes out of the box.

In various videos, memory-bank often appeared in clickbait titles like:

“Speed up your AI agent 100x by saving context and cutting token usage!”

That was… partly true.

But some limitations surfaced quickly:

either you have one big bank across all projects (which sometimes confuses them and creates new banks randomly),
or a separate workspace for each project — which is inconvenient.

Soon it became clear: a .md file could do 80% of what I needed.
You can simply write your context and tell the model (via .rules) to always read it — because, well, we do have hands.
Then I started including not just architecture notes but also plans, problems, steps, and key decisions.
All in a separate file — since .rules should stay universal and project-independent.

Boomerang Tasks and Spec Kit

Then I watched a few more videos and got the feeling that I was doing something “wrong,” while serious people were doing it properly.
So I tried Boomerang Tasks (with RooCode) and Spec Kit.

Boomerang didn’t show real advantages over a regular .md context/plan file, especially since the file can be edited directly, instead of waiting for the plugin to “catch up.”
Maybe it was the backend’s fault, but that’s also the point: Boomerang is tied to RooCode, while your context file works equally well with Droid or Windsurf.
That flexibility matters, especially when you prefer a lightweight, cost-efficient setup.

With Spec Kit, results were similar.
When refactoring a small 2D game on Go + Ebiten + ECS, the very first “refactor step” expoded the scope and hit the daily token limit before finishing.
In the end, Spec Kit didn’t replace my manual, more controlled way of defining refactoring steps.
You don’t expect a “serious” tool to face same problems as your homegrown scripts — but it happens.
That was the end of my Spec Kit story.

Lessons Learned

These trials taught me a few things. Now I work like this:

Ask the AI to analyze project problems and produce two plans — minimum and maximum (in the Leninist sense: program-minimum and program-maximum).
Execute the minimum plan.
Review the maximum plan separately — decide which steps to split or delay.

If I’m starting a new project, I may use Spec Kit — but often a simple plan made with chat is a good starting point that followed with manual fixes and careful revision.

For now, doing it in chat+hands manner, without fully automated task slicing gives better results.
Why?

a) the project context stays with you,
b) one or two .md files are far easier to manage than those monstrous setups like memory-bank or Spec Kit.

Why I Still Value Manual Control

Why keep manual control where an AI agent could technically handle everything — if only you crafted the perfect prompt?

Two reasons.

First:
When working on large projects, heavy vibe-coding quickly makes the project no longer yours.
For simple cases it doesn't matter.
But when working with edge cases, memory allocation trade-offs, algorithmic subtleties or complex component dependency (like in game dev), preserving project knowledge is critical.

Vibe-coding destroys that knowledge fast.
I’ve found that maintaining a few manual steps helps me stay in sync with the project and skip (or severely reduce) the “re-read everything every few days” routine.
In this sense, local .md files are useful: simple, transparent, and preserving the best parts of tools like memory-bank or Boomerang Tasks without their overhead.

Second:
A good prompt usually appears after a few hours of bad ones.
Experience and understanding, as I see it, come only through the struggle.

Final Thought

Automation is powerful, but context ownership is better.

If the tool starts thinking for you, it will also start forgetting what you meant.
A plain .md file won’t do that, but it gives you just enough automation support, keeps things easy to handle by yourself, and offers a kind of two-chair balance between automation and manual work.