Cyborg Resilience Co-lab — All updates

Blackout Preparedness Kit: Slide Deck Download (Action! Grey-Zone Survival Guide Forum)

2026-08-30T00:00:00+08:00

CHENG PENG spoke on behalf of CRC Cyborg Resilience Co-lab at the “Action! Grey-Zone Survival Guide: Information Warfare Analysis ✕ Offline Communication Forum”. The forum was co-hosted by Doublethink Lab, Watchout, and CRC Cyborg Resilience Co-lab.

Slide deck download

CHENG PENG, Blackout Preparedness Kit: https://drive.google.com/file/d/1RtH03YMiR1zPndD-mCebYJMf6FQiR8hb/view?usp=drive_link

About the forum

【Action! Grey-Zone Survival Guide: Information Warfare Analysis ✕ Offline Communication Forum】

Doublethink Lab ✕ Watchout ✕ CRC Cyborg Resilience Co-lab

🚨 What is “grey-zone” warfare?

Many people assume a war begins with missiles landing and air-raid sirens blaring. But in modern hybrid warfare, an adversary’s most common approach is grey-zone operations — more covert and harder to guard against — including subsea cable disruption, cyber intrusion and data theft, and cognitive manipulation.

They leave us feeling worn out and powerless about the present without even noticing, sinking into learned helplessness.

Their true aim is to “gradually change the strategic status quo without triggering full-scale military conflict, dismantling Taiwan’s internal will to resist step by step.”

▍What you will learn at this forum:

Seeing through threats: dissecting the newest grey-zone cyber operation tactics of 2026.
Mental defense: building a personal line of cognitive defense against information warfare and emotional manipulation, and rejecting black-and-white extreme narratives.
Blackout backup plans: hands-on analysis of a 30-minute connection-throttling drill! A rundown of offline tools and practical fallbacks for when critical communications are blocked.
Interactive experience: try young creators’ knowledge-translation works in person, letting preparedness awareness blend naturally into daily life.

The 2026 Urban Resilience Exercise: Your 30-Minute Network Survival Guide

2026-07-28T00:00:00+08:00

Three settings, three screenshots, three agreements and you will get through this exercise just fine. This is only mobile data throttling — you can still make calls and send texts!

※ For the actual dates, times and content of the exercise, please follow the announcements of the government authorities ※

Check the time and place of the exercise first — 30 minutes each

Once the exercise starts, browsing on your phone’s 4G／5G, and the hotspot you share to laptops and tablets, will be extremely slow

Phone calls, text messages, disaster warning alerts, 110／119: all normal

※ For the actual dates, times and content of the exercise, please follow the announcements of the government authorities ※

Change 3 settings

All of them are free features built into your phone or computer — a few taps and they are working.

1. Set up offline maps Google Maps → tap the profile picture in the top right → “Offline maps” → “Select your own map” → download the area around your home, the area around your office, and everywhere else you regularly pass through.

2. Set cloud files to be available offline For the slide decks, quotations and contract PDFs you need that afternoon, right-click them on Google Drive／OneDrive／Dropbox or whichever cloud drive you use and choose “Available offline” or “Always keep on this device.” Do it once in the mobile app as well.

3. Save music and videos Download the podcasts / music / videos you want for your commute in advance.

Once you are done, remember to turn off all Wi-Fi + switch on airplane mode, and test that these offline files really work.

Take 3 kinds of screenshots

Just save them to your photo album — you can look at them without a network.

1. Phone numbers Family, school／after-school care, your manager, the clients you need to contact that day. Plenty of people only have someone’s LINE and have no idea what their mobile number is. Remember to copy them onto a slip of paper for your wallet too — that survives a dead phone battery.

2. That day’s schedule Meeting times, places, the other party’s name and phone number.

3. Tickets and addresses For paid high speed rail and Taiwan Railway bookings, screenshot the “booking code (number)” and then collect the paper ticket with the booking holder’s ID; event QR codes, the street addresses you are visiting, and the shelters near your home／office (you can look these up in the air-raid shelter section of the National Police Agency, Ministry of the Interior, or download the 「警政服務」 police services app in advance and save the offline map inside the 「消防防災 e 點通」 fire and disaster prevention app).

Note 1: Both the high speed rail and Taiwan Railway companies explicitly prohibit the use of screenshotted ticket QR codes.

Note 2: For rules on screenshotting event QR codes, please follow the terms of each organization/company.

Make 3 agreements

It doesn’t cost a cent — you just have to say it out loud.

1. To family, elders and friends “Between 2:30 and 3:00 pm on 8/13, LINE messages may not go through — that’s the network throttling drill. If anything comes up I’ll call you directly, and you can text me.” → This one sentence saves the other person a whole afternoon of anxiety~

2. To colleagues “No online meetings during this half hour.” Move the 14:30 video call earlier to 14:00, or later to 15:10; if it absolutely has to happen, switch it to a voice-only call or walk over and talk face to face.

3. To colleagues out in the field and whoever picks up the children Agree on a “check-in time ＋ meeting point,” for example “I’ll call you at 15:00; if you can’t get through, wait for me in the ground-floor lobby.” Whenever you cannot reach each other at the agreed time, head instead for the fixed meeting point you settled on in advance.

14:20 on the day: a 3-minute wrap-up

Approvals, reports and attachments you send from your phone: hit send before 14:25 and don’t cut it fine.
If your company systems, VPN or online banking need push verification from a phone app, log in on your computer beforehand and don’t log out during that half hour (systems that use SMS verification codes are unaffected)
If you need to place an order, transfer money or upload a tender, handle it on a computer on fixed broadband, or simply avoid this half hour
Wallet check: cash ＋ a physical EasyCard／iPASS ＋ a physical credit card. When the connection is very slow, the payment barcode in a mobile payment app may not open.
Check that your laptop is on the office Wi-Fi rather than your own phone hotspot

14:30–15:00: how to spend these 30 minutes

Things you can do

Connect to the fixed-broadband Wi-Fi at the office or at home and you will barely notice a thing
If you need someone, call them; if it isn’t urgent, text them
Schedule it as an “offline work block”: proofread on paper, write documents, tidy your desktop, walk over and finish a conversation with a colleague

Things not to do

Don’t hammer refresh. The more people retry, the slower it feels
Don’t go changing network settings or the APN — it is very easy to forget how to change them back afterwards
Don’t rush to call your telecom’s customer service

After 15:00

If the network doesn’t come back on its own: switch airplane mode on for 10 seconds and then off again, or simply restart the phone.

Then spend two minutes asking yourself one question: which thing just now was the most stuck? Was it not being able to find someone’s phone number, not being able to pay, or not being able to open a file? Write it down — because when the network is damaged by a real typhoon or earthquake, nobody announces the time in advance.

Further reading: Why Run a Mobile-Network Throttling Drill? Is There Any Point?

※ For the actual dates, times and content of the exercise, please follow the announcements of the government authorities ※

Why Run a Mobile-Network Throttling Drill? Is There Any Point?

2026-07-22T00:00:00+08:00

Taiwan ranks among the world’s best for mobile data pricing, connection speed, and connection quality. That is the fruit of years of construction and maintenance by the three major telecom operators and the government, and it is why the public enjoys a mobile network environment that is both stable and inexpensive.

Taiwan is also, however, a country where typhoons and earthquakes are frequent. Beyond damaging water supply and the power grid, natural disasters also reach network and communications equipment such as base stations and cables: the magnitude 7.2 Hualien earthquake of April 3, 2024 affected 172 mobile base stations at its peak (mostly concentrated in the Yilan–Hualien area)[1]; in July 2025, Typhoon Danas put more than 1,300 base stations in and around the Chiayi–Tainan area out of service through power loss or damage[2][3], and some of them were not fully repaired until the end of October that year[4]. A mobile network outage does not just make it hard for residents of a disaster area to reach family and friends; it also obstructs the coordination of relief work.

It is worth noting that damage to base stations mostly produces a “localized outage,” whereas damage to Taiwan’s international subsea cables could produce an “island-wide slowdown”: the core servers of many everyday apps and websites sit overseas, so once international bandwidth drops sharply, services will still stall badly even when the domestic network is working normally. The “Digital Resilience Forum: Subsea Cables and Network Infrastructure in an Age of Geopolitics”, held by Cyborg Resilience Co-lab (CRC) on March 25 this year, ran a simulation and analysis of exactly this kind of partially damaged network scenario[5]; one of its conclusions at the time was that “drills, whether run by government or by civil society, need to include scenarios in which the network is damaged.”

The government has long promoted disaster prevention and relief education and evacuation drills, so that people become familiar with response procedures before a disaster arrives and build the capacity to handle sudden situations. The core of disaster mitigation (and prevention) is to reduce the impact of natural disasters on daily life as far as possible; as everyday life grows more dependent on the internet, “network slowdown or outage” should be brought into drill scenarios too.

Drills of this kind, dealing with networks and communications, are not unprecedented internationally: the “Council for Emergency Communications” (Japanese: 非常通信協議会), formed by Japan’s Ministry of Internal Affairs and Communications together with telecommunications organizations, regularly runs “emergency communications training,” in which disaster information is relayed over backup power and alternative communications circuits when public lines and disaster-prevention radio are down[6]; South Korea’s 2025 “Ulchi exercise” (을지연습) mobilized roughly 4,000 agencies and 580,000 people, with scenarios covering not only communications outages and destruction of network infrastructure but also GPS jamming[7]; and NATO’s Cooperative Cyber Defence Centre of Excellence (CCDCOE) holds Locked Shields, the world’s largest live-fire cyber defense exercise, in Tallinn, Estonia every year, mobilizing 41 nations and more than 4,000 people to practice defending critical infrastructure, including scenarios in which communications infrastructure is destroyed[8].

Finland has gone further still: for nine consecutive years the Digital and Population Data Services Agency (DVV) has run the nationwide “TAISTO” cyber and information security exercise, open free of charge to every public-sector organization, with more than 450 agencies and institutions taking part in recent editions; working with the police and national security agencies, it simulates scenarios such as cyberattacks, systems being hacked, and even AI information security[9].

This year’s Urban Resilience Exercise includes a “mobile network throttling” drill for the first time: starting at 2:30 pm on August 10 (7 central counties and cities) and August 13 (7 northern counties and cities), it simulates the shortage of bandwidth that follows the activation of disaster roaming and tiered traffic limiting, throttling speeds for 30 minutes; voice calls, SMS, Public Warning System cell broadcasts, and emergency numbers such as 110 and 119 are all unaffected, and Wi-Fi running over fixed broadband is unaffected as well[10]. The public can use the occasion to practice alternatives such as offline maps, cash payment, and reaching people by phone number, preparing in advance for the natural disasters that may come.

We are glad to see this item added to this year’s exercise, and we hope future exercises and disaster-prevention education will keep broadening and deepening scenarios related to digital resilience!

With half a month to go before the exercise, CRC will share next week how to prepare for the “mobile network throttling” drill. We’d love for all you brilliant people to leave a comment and share what you, your family, or your friends have already arranged for this one~~

References

Central News Agency, “Strong quake affects 172 base stations across the three major telecom operators; NCC estimates repairs today,” April 3, 2024.
Executive Yuan, “Typhoon Danas response measures and recovery status” (figures as of July 9, 2025; 1,360 base stations damaged).
United Daily News, “Typhoon Danas devastates communications in Chiayi–Tainan; NCC activates disaster roaming to avert digital isolation” (1,293 base stations in southern Taiwan knocked out by power loss or damage).
Central News Agency, “Typhoon Danas devastates base stations; Chunghwa Telecom: restoration scheduled by the end of October,” August 4, 2025.
CRC Cyborg Resilience Co-lab, “Digital Resilience Forum: Subsea Cables and Network Infrastructure in an Age of Geopolitics”, March 25, 2026.
Council for Emergency Communications (非常通信協議会), 非常通信確保のためのガイド・マニュアル.
이치저널, “드론과 GPS가 멈춘다”… 전 국민이 훈련에 들어가는 3박 4일, 2025 을지연습, August 2025.
NATO CCDCOE, “Locked Shields.”
Digi- ja väestötietovirasto (DVV), “TAISTO-harjoitus”; see also the DVV press release.
Central News Agency, “Urban Resilience Exercise: phones throttled, not disconnected, across 14 counties and cities — the affected scope explained in one read,” July 21, 2026.

Meshtastic Beginner Workshop

2026-07-19T00:00:00+08:00

Do you often hear people say, “When the internet goes down, you can use that Mesh thing!”? If you have, it means you have been following the question of how to communicate after an internet outage. If you have not, but care deeply about what happens if the internet goes down, this is also an opportunity to start learning.

What Is Mesh?

Mesh literally means a net. The term is commonly used for networks and communications arranged in a mesh structure: instead of relying entirely on a single centralized transmission point, such as a cellular base station, multiple devices connect to one another to form a network that can pass messages among them.

What Is Meshtastic?

Meshtastic is one technical system for mesh networking. It is also an off-grid communications option often discussed by Taiwan’s civil society, with a highly active community building networks and exchanging technical knowledge. Meshtastic uses LoRa radio technology to form a decentralized mesh communications network among devices without relying on cellular networks, Wi-Fi, or the internet.

In this beginner workshop, we will start from scratch and introduce how Meshtastic works, how to choose hardware, how to install the software, and how to complete the basic setup. Beginners encountering Meshtastic for the first time are welcome to bring their own devices. Those without a device are also welcome to come listen, and a small number of devices will be available on site for everyone to try out.

Event Information

Time｜Sunday, July 19, 10:30–12:00
Venue｜Impact Space, 2F, NPO Hub
Space is limited and advance registration is required (registration for this event has closed)

CNA Coverage: Lee Tzu-Tung’s Solo Exhibition “Mercy and Vengeance in the Bardo” in Sweden

2026-07-01T00:00:00+08:00

Thank you to CNA for the coverage!

CRC artist #LeeTzuTung recently presented the solo exhibition Mercy and Vengeance in the Bardo in Sweden. Through artworks and workshops, the exhibition considered forms of violence ranging from gender-based violence to posthuman warfare, as well as how people can seek possibilities for healing and resistance within them.

Among the works, The Temple of the Wandering Daughter continues our shared exploration at CRC of posthuman warfare, drones, and the politics of technology. As war becomes both “remote” and “everyday,” and as machines, algorithms, and infrastructure are increasingly weaponized, how can we rebuild relationships, memory, and resistance?

CRC Begins Its C-LAB Residency: Two Public Talks and a Year-End Presentation

2026-06-29T00:00:00+08:00

Following last week’s “Practicing Survival at the Edge of the Wasteland,” our cross-disciplinary art and technology work is now taking up residency at Taiwan Contemporary Culture Lab (C-LAB).

People on the front line in Taiwan have long been immersed in the experience of modern gray-zone warfare—through one AI account after another, repeated incursions by Chinese military aircraft, successive war games, and stacks of emergency handbooks. Some people become anxious and hypersensitive, while others do not know where to begin caring.

Led by our team’s artist and curator #LeeTzuTung, CRC is inviting everyone to go beyond the hard technologies of digital communications, such as networks and resilience, and use art, hands-on making, and other approaches to understand this “Schrödinger’s state of war preparedness” and feel the complicated texture of everyday life in Taiwan.

Preview of Activities in the Second Half of the Year

2 public talks
1 year-end presentation

Event details will be announced progressively. Follow CRC for the latest updates.

Practicing Survival at the Edge of the Wasteland

2026-06-27T00:00:00+08:00

Time｜Saturday, June 27, 14:00–16:00 Venue｜Co-Space

Taiwan is an island beset by disasters: everyone fears for themselves, yet everyone also trains themselves. Approaching the subject through civil defense, digital resilience, and primary healthcare, this talk discusses how a new kind of organizer outside traditional organizational structures can develop agency in high-risk environments, and how a sense of crisis can be transformed into training, knowledge, and mutual-aid networks.

Speakers

Frontline Democracy Project｜Yi-Cheng Liu (ARTICLE 19 Asia-Pacific Programme Officer)
Cyborg Resilience Co-lab (CRC)｜Lulu Keng
Local Snake Project｜De-Ray Chen

Interpretation

CEO of RC Culture and Arts Foundation, interjector on the podcast Human Zoo, and president of Praxis Society｜Chun-Kai Wang

Rti Coverage: Taiwan’s Community Meshtastic Coverage Has Reached 80%

2026-06-15T00:00:00+08:00

Special thanks to Rti for its coverage!

“Sean Ching said that the community had only about 50 members in its early days but has now grown to nearly 20,000 people across Taipei, Taichung, Kaohsiung, Hualien, and other parts of Taiwan, with an estimated 1,000-plus devices in operation… As more and more people build their own systems, coverage across Taiwan has reached approximately 80%, and Meshtastic can now be used to communicate in most inhabited areas.”

Does communicating by Mesh sound a little more feasible than pulling a battery from an electric scooter?

But how should radio waves that bounce from point to point adapt to cities full of walls and interference, and to the opposite conditions found in rural and mountainous areas?

One session on CRC’s digital resilience track at g0v Summit 2026. The headlines excerpted below capture the report’s key points:

Meshtastic: Build Your Own Offline LINE in One Afternoon for NT$1,000
Meshtastic Taiwan Community Coverage Has Reached 80%
Is Meshtastic Really a Good Communications Alternative?
Do Ordinary People Need to Prepare Meshtastic?

Rti Coverage: Communications Resilience During Internet and Power Outages

2026-06-08T00:00:00+08:00

Special thanks to Rti for its coverage!

“But when a power-grid outage shuts down cellular base stations, how can a household power its Wi-Fi router? Michael explained that routers generally require only 10 to 28 volts, so vehicle battery modules, such as electric-vehicle batteries, are a particularly convenient and readily available source of electricity in an emergency and can ensure that internal communications networks continue to function soundly.”

BUT, but, but—the situation above is only an emergency simulation. Do not reach for the nearest electric-vehicle battery station just yet; be careful not to break the law 🔋

One session on CRC’s digital resilience track at g0v Summit 2026. The headlines excerpted below capture the report’s key points:

Confronting an internet-outage crisis: real-world experience from Ukraine and Myanmar
If every subsea cable is severed, LINE may fail even if its data center is in Taiwan
Ukraine: building domestic communications networks with alternatives to both Facebook and LINE
Could PTT become Taiwan’s version of dComms?
What happens when the power goes out? The Gogoro battery on your street corner
What should we prepare before a crisis arrives?

Offline Mission Accomplished: On-Site Report from g0v Summit 2026

2026-05-24T00:00:00+08:00

Thank you to everyone who took part in the “Offline Action”!

More than 180 participant turns, 67 minutes of relay pedaling, and a total distance of 9.2 km on a flywheel generator sent a steady stream of resilience messages to the Meshbridge message board. Dozens of participants at the venue also connected successfully to the message board over Wi-Fi. Better still, Reticulum robots exchanged 6,759 messages over two days—enough to make us wonder whether they were secretly developing a social circle of their own!?

CRC hereby formally declares: this Offline Action was mission accomplished!

Thanks to #g0vsummit2026 and OpenFun for their collaboration.

Slides from Our Panel Discussion at g0v Summit 2026

2026-05-24T00:00:00+08:00

Presentation links from the digital resilience event series at g0v Summit 2026:

Digital Lifeline: Everything You Need to Know About Subsea Cables

Sean Chou: https://docs.google.com/presentation/d/1Pj9pSy5K9w1ehX5dsC7cOoDFwmkwbCS2cEdn2K981sc/edit (All rights reserved)
Athena Tong: https://drive.google.com/file/d/1X0F9t83NNC7mw5-82mB0jen2mLDl2EdU/view (All rights reserved)
CHENG PENG: https://paulpengtw.github.io/crccolab-implications-of-internet-traffics-drop-to-50-percent-and-what-to-do/ (License: CC BY-SA 4.0)

After the Blackout: Off-grid Communication Solutions in Ukraine, Myanmar and Taiwan

Sean Ching: https://docs.google.com/presentation/d/1OhzajvjjwuUDTEJsLs23il_z6JHUp86_YGE6GeM3hGY/edit (License: Beerware)
Aidan: https://drive.google.com/file/d/1Kf45_w129YS3GOH7H_hPnFn-o1cOOsyC/view
Michael Suantak: https://drive.google.com/file/d/1GSPfOFlLUVFZg3a49uUmzgSovpkLntdc/view

Slides on Subsea Cables and Meshtastic Taiwan, Invited by RSF

2026-05-06T00:00:00+08:00

Thanks to Reporters Without Borders (RSF) for inviting us to share about the subsea cable issue and the Meshtastic Taiwan community. The presentation slide decks follow:

CHENG PENG’s slide deck: https://paulpengtw.github.io/crccolab-May-6-2026-why-cable-cuts-matters/ (License: CC BY-SA 4.0)
Sean Ching’s slide deck: https://docs.google.com/presentation/d/12XXii10OHNy3xO8sI9PzjoscqG5FojyzFT7FaBgDScc/edit (License: Beerware)

Coming Soon: Digital Resilience International Hackathon 2026 · CRC × OpenFun

2026-05-02T00:00:00+08:00

The subsea cables that connect the internet have recently become a major focus. Surrounded by sea, Taiwan is especially sensitive and vulnerable to changes affecting subsea cables, and even more so amid unstable geopolitics. When the internet truly disappears, can we still get a message out?

CRC and OpenFun Inc. are co-organizing this two-day event, inviting practitioners from Ukraine (dComms), Myanmar (ASORCOM), and Taiwan to share how they have used alternatives such as Meshtastic, Reticulum, federated protocols, and local servers to build off-grid communications resilience in war zones, jungles, outlying islands, and remote rural communities.

Dates: Saturday, May 23, warm-up action · Sunday, May 24, one-day hackathon Venue: Humanities and Social Sciences Building, Academia Sinica (Nangang, Taipei) Format: Themed talks · Roundtable discussions · Side-event communications challenge

【Panel Sessions｜Sunday, May 24】

Digital Lifeline: Everything You Need to Know About Subsea Cables (10:30–12:00)
After the Blackout: Building Communications-Resilience Networks in Ukraine, Myanmar, and Taiwan (13:00–14:30)
Digital Resilience Lab: Off-grid Network Technical Exchange (15:30–16:30)

【Side-event Challenge｜Saturday, May 23, and Sunday, May 24】

A communications breakthrough mission spanning the entire Humanities and Social Sciences Building—operate a Meshtastic message board, send Reticulum transmissions across different media, and even dispatch “messages by carrier pigeon” as you break through each constraint, one checkpoint at a time!

Event details: crcolab.art/events/hackathon-2026/

Kuma Academy: “When the Internet Goes Down, No One Has a Backup Plan”

2026-04-20T00:00:00+08:00

“It is precisely because the internet is so convenient that when it goes down, no one has a backup plan.”

This observation arose from Sean Ching’s survey and review of Taiwan’s communications infrastructure. Thanks to the efforts of people working in the relevant organizations, Taiwan’s telecommunications networks have not experienced a large-scale outage lasting more than half a day in recent years. If an outage occurs in a major city, it can generally be resolved within 24 hours. Yet this very convenience leads us to take the internet and electricity for granted, like air—so people panic intensely when the internet goes down. For this reason, civil society has begun researching and discussing Meshtastic as another communications backup.

How Far Do Communications Actually Need to Reach?

Most people commute for 30 to 60 minutes each day, equivalent to a typical range of approximately 10 to 30 kilometers. In other words, when a disaster occurs and communications are interrupted during the gap before repairs are completed, people do not need long-distance communications between Taipei and Kaohsiung. They want to know whether family and friends are safe in a short-term, localized emergency—and that is precisely the setting in which Mesh performs best. In theory, point-to-point communications can reach 3 to 5 kilometers even in a concrete urban jungle full of interference. With relay capabilities, Mesh can easily cover an ordinary commuting range; in open terrain, the distance can increase dramatically to 30 kilometers.

Experience from Taiwan’s Community

Taiwan’s largest Mesh Facebook group, “Meshtastic Taiwan Community (Taiwan Mesh Network),” includes many experienced members who can help answer all kinds of questions encountered while operating Mesh. More importantly, Taiwan’s community created the “MESHTW” channel so enthusiasts could contact one another and run tests. A stable communications network has now formed across northern Taiwan. Sean also reminded members of small teams to test their equipment periodically and establish trusted communications networks and rules of use within trusted circles.

The Latest Application: “Meshbridge Message Board”

Using Mesh still requires every user to have a hardware device and a mobile app—but could “a group own just one device, yet share its network and use it to communicate with the outside world”? Motivated by this possibility, Sean and fellow enthusiasts combined Mesh with a Raspberry Pi to complete the Wi-Fi-enabled Meshbridge project. Even users without Mesh hardware can connect directly to the Mesh communications network using their phone’s Wi-Fi, then open a Chrome page to chat and leave messages. By greatly lowering the technical and financial barriers to promoting Mesh communications backups in residential buildings, this is an exciting Mesh development project.

(This article was compiled and written by Kuma Academy.)

DSET Coverage: Comparing Taiwan’s and Ukraine’s Cyber Defense Experience

2026-04-10T00:00:00+08:00

On March 25, DSET Adjunct Research Fellow Jen-Wei Chang represented the institute at the “Digital Resilience Forum,” organized by Cyborg Resilience Co-lab (CRC) under the theme “Subsea Cables and Network Infrastructure under Geopolitical Pressure.” He shared experience from #Ukraine’sWartimeCybersecurityAndCommunicationsOperations and offered policy recommendations for Taiwan.

This Digital Resilience Forum was jointly advanced by communities including Cyborg Resilience Co-lab (CRC), g0v.tw Taiwan Zero Government, and the Open Culture Foundation. It was moderated by CRC co-founder Meichun Lee and Open Culture Foundation CEO Hsin-Ying Lee. DSET participated in the forum’s second session, joining representatives from the Institute for National Defense and Security Research, the Ministry of Digital Affairs, and civil technical communities to discuss digital resilience.

Drawing on cases of wartime cyberattacks in Ukraine, Jen-Wei Chang explained that digital resilience is not improvised only after a crisis begins; it is grounded in ordinary network infrastructure and the capacity for rapid wartime coordination. He said that Ukraine not only has a more diverse network structure and cross-border interconnection conditions, but has also kept critical communications operating during the war through measures including #NationalRoaming, #SatelliteBridging, #EmergencySpectrum, #BackupPower, and #ContinuousRepairs. The latter combined-response approach is especially worthy of Taiwan’s attention.

He further noted that although Starlink is important, it is not a stand-alone solution that can operate independently of existing infrastructure. Taiwan’s urgent priority is to build a national network architecture that is multilayered, uses multiple providers, and can allocate resources by priority level, while taking stock of risks involving coordination across operators, routing sovereignty, and domain governance.

Because Taiwan relies heavily on subsea cables for international communications, core issues that must be clarified early include maintaining priority for essential traffic, service outages that overseas rerouting may cause, and whether critical control layers can operate independently within Taiwan. Communications governance issues involving DNS and BGP also require international cooperation. Incident reporting, forensic collaboration, and overseas backup mechanisms between Taiwan and its allies still need further institutionalization and transparency.

Jen-Wei Chang said that Taiwan’s next step should place “continuous operation” at the heart of digital resilience, strengthen redundancy at critical nodes, and use combined exercises across agencies and operators to transform international experience into locally viable solutions.

(This article was written and compiled by DSET.)

Event Recap: Digital Resilience Forum, First Session

2026-04-01T00:00:00+08:00

As a child, I thought that when a subsea cable broke, the internet broke: I was on this side, and the world was on the other. As an adult, I thought that full signal bars meant service, never realizing that the homepage was on this side while the data was on the other. Only after the first subsea cable forum did I understand that a real disconnection does not mean having no signal. It means everything appears connected, yet everything you can use is on the other side of the sea.

Highlights from the speakers in “Section 1: Subsea Cable Topics and Technical Reports”—to understand subsea cables and internet risks, let us look at this side, here at home, before looking at the other side overseas.

Three Speakers and Two Projects on the Structural Risks in Taiwan’s Domestic Internet

The complexity of “internet services” comes from connections both within Taiwan and across borders, as well as an intricate layered structure. Even if only some subsea cables are severed and outbound internet traffic falls by 50%, users may still experience internet services failing layer by layer under conditions of “congestion collapse” and as authentication and authorization credentials expire one after another. Identifying which layer fails, what it affects, and how it can be reinforced is the key to an effective response.

Risk 1: Domestic internet routing and peering are matters of business models. If local telecom providers do not peer with one another, or if they “cannot agree on transit fees,” services that could have interconnected within Taiwan may instead be routed through overseas paths such as the United States or Japan before returning. Ordinarily, this adds only 20–30 milliseconds, but the risk rises rapidly once traffic is throttled or subsea cables malfunction.

Risk 2: Subsea cable information is opaque, making problems difficult to see. The composition and segmented functions of domestic and international subsea cables are complex. Before a dynamic subsea cable map existed, telecom companies often shifted responsibility for slower internet speeds to upstream or downstream vendors, digital service providers, or other outside parties, making it difficult for ordinary people to pinpoint the problem accurately. Once open-source intelligence (OSINT) and other public geospatial data are consolidated into visualized information, subsea cable status becomes trackable. This can help everyone recognize that slower internet and failed services are not necessarily problems with a single provider or website.

Risk 3: Taiwan has not sufficiently inventoried essential digital infrastructure services. The “Digital Service Resilience Testing” project surveyed the homepages of the 2,000 most commonly used website services and found that 89% of websites are at risk when subsea cables are severed. Any involvement of layered infrastructure such as domestic and international data centers, nodes, cloud services, hosts, and servers can expose a service to disruption; cloud services, for example, are highly concentrated among providers such as Google, Amazon, and Cloudflare. At the same time, the 11% that passed the test are not necessarily truly safe: their databases, apps, third-party resource services, and other pages may not be hosted in Taiwan. Taiwan’s real problem is not simply whether subsea cables will break, but which services matter most, where their chains of dependency lie, and how many are already bound to infrastructure overseas.

What Taiwan Should Do Next

Make subsea cable information and measures more open and transparent, including abnormal conditions, repair progress, and risk explanations. Taiwan should also promote routine testing and disclosure so that vulnerabilities in essential digital services can be seen before an incident occurs.
Expand domestic peering channels and encourage cooperative interconnection among telecom providers. This would reduce the amount of traffic that could be routed domestically but is instead forced overseas, lowering risks when subsea cable capacity is constrained.
Inventory the dependency chains of public infrastructure and essential digital services as soon as possible, and establish backup plans inside and outside Taiwan, including data centers, cloud services, authentication mechanisms, and critical systems that support people’s basic needs.
Much—more—public education, so that society understands the relationships among subsea cables, the internet, and digital services.

Constraints Imposed by Governance beyond Taiwan on Subsea Cable Issues

Constraint 1: National borders. Under the United Nations system, the 1982 United Nations Convention on the Law of the Sea established boundaries for maritime jurisdiction: territorial seas may extend no more than 12 nautical miles, while contiguous zones may extend to 24 nautical miles. Thus, although subsea cables may appear to be borderless infrastructure, a nearby government cannot simply send a ship to repair a break wherever it occurs. Maritime jurisdiction, vessel authority, and international coordination are also involved. These constraints greatly limit subsea cable tracking, protection, and repair, make it difficult to grasp conditions promptly, and often require catching perpetrators in the act before they can be held accountable.

Constraint 2: Financial realities. Public authorities cannot simply send government vessels into another country’s waters to address subsea cable problems. Could the private sector solve the problem through commercial ports? Once commerce is involved, funding comes first. Large work vessels truly capable of repairing subsea cables have a basic construction cost of approximately US$100–300 million, while specialized work vessels cost approximately US$15 million per year to operate. Moreover, telecom companies earn most of their revenue from laying new subsea cables, not repairing them, which makes maintenance itself less likely to become an area the market naturally prioritizes.

Managing Digital Infrastructure with a “Disaster Prevention” Mindset

Because the governance constraints described above make rebuilding and maintaining subsea cables extremely difficult, risk management should follow a linear before, during, and after-disaster framework.

Before a disaster: Reduce the likelihood that subsea cables will be damaged—raise the cost of sabotage through fines, confiscation of tools, deeper burial, physical protection, and early-warning systems. At the same time, minimize impacts by continuing to add backup cables, maintain systems, and back up data. International cooperation should also be encouraged, matching resources so that operators can build more subsea cables and maintenance systems.
During a disaster: Once a subsea cable is interrupted, the priority is to switch traffic to backup cables or systems as quickly as possible, while tracking the situation through the subsea cable information section, operator reports, and interagency collaboration.
After a disaster: Taiwan still relies on foreign repair vessels for support. Beyond accelerating repairs, the more important work afterward is to review the cause of the interruption, press the industry to strengthen security protections, and continue promoting interagency collaboration.

Community Perspectives and Lessons from Other Countries

From the community’s perspective, the concern behind the subsea cable issue is how society can continue to function when the internet goes down or slows dramatically. Rather than discussing only the worst-case scenario, it is more important to turn risks involving different degrees of interruption and different causes into scenarios; identify the most probable, highest-risk situations requiring priority response; and then use community collaboration and practical exercises to turn responses from ideas into practice. Conditions along the First Island Chain are relatively similar, so Taiwan can refer to the disaster-preparedness exercise strategies and cooperative repair and defense measures used in countries such as Japan and the Philippines.

The Ukrainian case suggests that Taiwan should learn to think in terms of “combined attacks” and “whole-of-society resilience.” Ukraine has faced not only cyberattacks, but simultaneous pressure on government digital services, power systems, and physical infrastructure. Ukraine can locate off-site backups in European Union countries—but what can Taiwan do? Comparing these real-world cases further underscores the need for Taiwan to think ahead about cross-domain collaboration: whether data center control layers can operate within Taiwan, how essential traffic should be allocated, and how central and local governments can coordinate with one another during outages of different scales.

Rti Coverage: Digital Resilience Forum — Subsea Cables, Traffic, and Response Strategies

2026-03-27T00:00:00+08:00

Thank you to Rti for its detailed coverage of our event! Here are the key points:

Internet Access May Fail Even If Not All Subsea Cables Are Severed

Even if only half of the subsea cables are severed and Taiwan is not completely cut off from the world, collapse caused by congestion could bring the fundamental functions that keep the internet running to a halt. For users in practice, the experience could be just like a total outage.

Routing Traffic Overseas Is “Less Efficient and Riskier” but More Profitable

Internet service providers can manage traffic by allowing more important content to take priority over certain uses. CHENG PENG emphasized that in a crisis, ISPs can choose “whom to save.” This also highlights how ISPs ordinarily have the power to decide to “route your traffic overseas and then back again, rather than peer locally.”

There Are Multiple Ways to Respond to Subsea Cable Outages

Hsin-I Chen said that people previously viewed subsea cables as a commercial issue and only realized in the past two years that “subsea cables are also part of geopolitics.” As Taiwanese society pays more attention to subsea cables, it can strengthen measures to protect their security while also raising the cost to China of taking action against them.

He then offered two recommendations:

The Ministry of Digital Affairs could publish more real-time data about subsea cables, allowing developers to connect through APIs and learn “where a cable broke,” “why it broke,” and other information, thereby strengthening public awareness and vigilance.
Taiwan should build more subsea cables, particularly in the “waters off the east coast,” where the sea becomes deep immediately beyond the coast. Compared with the waters off western Taiwan, cables there would be less vulnerable to damage, making the area highly suitable.

CRC Digital Resilience Forum: Simulating a Drastic Drop in Taiwan's International Internet Traffic

2026-03-25T00:00:00+08:00

Original slides and materials published at https://paulpengtw.github.io/crc-march-25-decks/.

Topic Outline

At the March 2026 Digital Resilience Forum, Cheng Peng presented a simulation titled “Degradation of Taiwan’s International Internet Traffic.” The scenario: submarine cables severed by an earthquake, causing Taiwan to instantly lose 50% of its international bandwidth (*note 1). The talk then walks through the cascade of failures likely to appear within the first six hours, VoIP calls (LINE voice, Messenger voice) dropping, web pages freezing, apps breaking one after another, accounts logging out, and the maddening experience of full Wi-Fi bars yet nothing loading.

This talk aims to explain the possible causes behind these network failures and what paths might mitigate their impact.

*Note 1: Losing half the submarine cables does not equal losing half the international internet traffic.

0–5 min

Phase 1: Why Did Voice Calls Suddenly Drop?

What You Might Experience

LINE voice call → robotic audio → disconnected ☎️❌
Instagram → blank screen
Google Drive → half-loaded, stuck
Glance at the top-right corner

Wi-Fi signal: full bars 📶

“Is It the Wi-Fi Router or the Internet?”

Full Wi-Fi bars ≠ working internet

📱 → 📡 Wi-Fi: your phone to your home router

This part is perfectly fine ✓

📡 → 🌏 Internet: your router to the rest of the world

This is where the problem lies ✗

The problem isn’t at home, it’s on the ocean floor.

What Is the Internet, Really?

Think of the internet as a system of thousands of post offices.

🏣 Each post office = a network node (ISP, data center)

✉️ Your data = individual letters (packets)

🛣️ Post offices are connected by many routes for relaying letters

Sending a letter from Taipei to Tokyo means it passes through several post offices, relayed from one to the next.

The internet isn’t a single line, it’s many nodes relaying data to each other. Each ISP and data center is like a post office. Your data is like letters, forwarded hop by hop to the destination.

How Does a Post Office Know Where to Send a Letter?

Every post office has a signboard out front 🪧

"Going to Japan? → Hand it to the post office to the south"

"Going to the US? → Hand it to the post office to the east"

"Going to Kaohsiung? → Hand it to the one next door"

This signboard, in networking, is called a routing table.

The way post offices keep each other’s signboards up to date is called BGP (Border Gateway Protocol).

A routing table is each network node’s “directional guide.” BGP is the protocol the global internet uses to synchronize routing information. No need to memorize the jargon, just remember: BGP = the system through which post offices notify each other “how to get there.”

Cables Cut = Routes Cut

The light beams inside the fiber vanish instantly (they’re severed, after all).

The post office nearest to the break is the first to notice: “This route is down!”

It immediately broadcasts to its neighbors: “Attention everyone! The southbound route is broken! Stop sending letters this way!”

The message starts spreading from one post office to the next…

Submarine cables are fiber optic. When severed, the optical signal disappears instantly, not a gradual fade, but an immediate zero. The router (post office) connected to that cable detects the link failure and announces via BGP to its neighbors: this route is no longer valid. That announcement ripples outward across the global internet.

The Chaos of Rerouting

BGP Reconvergence

Thousands of post offices worldwide receive the news, but not simultaneously.

🏣 Post office A has already updated its signboard ✓

🏣 Post office B doesn't know the route is down yet ✗

🏣 Post office C got the message but is still computing new routes ⏳

Your letters end up…

Sent down a route that’s already broken → lost
Bouncing back and forth between two post offices → looping
No post office willing to accept them → returned

This chaotic period: 30 seconds to several minutes

BGP reconvergence is the process by which the entire internet reaches a new consensus. The problem: information propagation has latency, and different nodes update at different speeds. During this transition, routing tables are in an inconsistent state, some routers think the old route still exists, others have already switched. This causes packets to be dropped, looped, or sent into dead ends. Duration depends on network topology complexity and BGP convergence speed.

To You, It Probably Feels Like, Everything Is Down

Packets dropped → web pages may not load

Packets rerouted the long way → latency may jump from 20ms to 2000ms

Packets looping → may never reach the destination

50% of international traffic is technically still there, but until routing reconverges, for the average person it may feel like total gridlock.

50% of capacity remains, but during BGP convergence it’s nearly unusable. It’s like a major highway pileup, the next lane is still open, but because the signs are scrambled, every car is stuck at the interchange. Once BGP converges (all signboards are consistent again), the remaining 50% can actually be utilized, but then congestion becomes the next problem.

LINE Voice May Drop, but Text Might Survive?

💬 Text messages

Tiny packets (maybe just a few KB)

Can squeeze through gaps in the chaos

A few seconds' delay doesn't matter

🎙️ Voice calls

Continuous real-time streams

Dropping a few packets = robotic voice

Latency over 300ms = call drops

What we're not sure about:

LINE's call servers might be in Japan?
Voice calls within Taiwan might have to cross the ocean to connect?

5–30 min

Phase 2: Zombie Internet

Entering Phase 2. BGP has finished reconverging and routing has stabilized. But people will notice: the internet is “alive” yet almost unusable. This phase explains two things: congestion collapse and the Trombone Effect.

What You Might Experience

Web pages half-loaded… stuck
Images half-rendered, the rest just gray
YouTube possibly spinning forever
LINE text barely sending, taking ages to deliver

Signal is full 📶, appears “connected,” but may be too slow to use.

Unlike Phase 1 (complete disconnection during BGP convergence), this is “connected but extremely slow”, which is actually more confusing. People keep refreshing and retrying, which only makes things worse.

Wait, Wasn’t the Route Fixed?

BGP reconvergence complete ✓, all post office signboards are consistent now.

The remaining 50% of international traffic works normally ✓, routes are open, letters can be delivered.

So why is it still this slow?

The routes aren’t broken, they’re just too crowded.

The previous phase’s problem was “scrambled signboards” (BGP convergence). This phase’s problem is “too few lanes, too many cars” (congestion collapse). Two completely different failure mechanisms, but to users they feel about the same.

Imagine a Highway

Taiwan’s international traffic = a 10-lane highway 🛣️

Normally, traffic fills about 7–8 lanes, there’s room to spare, everyone moves smoothly.

Losing 50% of capacity = suddenly only 5 lanes

But traffic volume hasn’t changed, same number of cars, half the road.

Highway analogy for congestion. Normally, submarine cable utilization is around 40–60%, so there’s headroom. After losing half, the remaining capacity is instantly saturated. Traffic doesn’t decrease just because there are fewer lanes.

The Chain Reaction of Gridlock

Why isn't it "half as fast" but rather "barely moving"?

🚗 Too many cars, some can't merge → packets dropped

🔄 Dropped cars say "Let me try again!" → back on the road

🚗🚗🚗 Everyone retrying → even more cars on the road

💥 More cars dropped → more retries → vicious cycle

This is called "congestion collapse"
Congestion Collapse

This is the core mechanism of congestion collapse. TCP retransmits when it detects packet loss. But when all connections retransmit simultaneously, they generate even more traffic, worsen the congestion, cause more packet loss, and trigger more retransmissions. This vicious cycle is congestion collapse.

Understanding It Through Letters

(Continuing the post office analogy)

You sent a letter to the US ✉️

Too much traffic on the route, the letter was lost → you never got a reply.

You think: “Probably got lost, let me send another!”, your computer thinks the same way (TCP retransmission).

Now imagine 23 million people in Taiwan, all with their phones "sending another" at the same time…

🏔️ Letter avalanche

TCP retransmission works great under normal conditions, occasionally drop a packet, just resend it. But under total congestion, everyone resending simultaneously becomes a disaster. It’s like everyone honking and cutting lanes during a traffic jam, it only makes things worse.

50% physical capacity ≠ 50% usable bandwidth. Due to the nonlinear effects of congestion collapse, once link utilization exceeds a certain threshold, effective throughput drops sharply. Some studies show that under severe congestion, effective bandwidth utilization can drop to 15–20%.

What Your Experience Might Look Like

📄 Web pages → text may load, but images spin forever

🎬 Video → possibly 240p pixelated, constantly buffering

📥 Downloads → speeds may drop from 100 Mbps to 2 Mbps

📱 Apps → may open, but every action takes 10+ seconds

Not disconnected, but slow enough to make you cry qq

This is the concrete impact of congestion collapse. “Too slow to use” is worse than “completely offline,” because you keep retrying, keep waiting, wasting huge amounts of time. And you can’t tell if it’s your problem or the entire network.

The Next Problem Is Even Stranger

Some websites have servers physically in Taiwan, theoretically don’t need international routes, and shouldn’t be affected.

But they may also be broken 🤯

Why?

Congestion collapse explains “why international traffic is slow.” But next we need to explain an even more bizarre phenomenon: why services whose servers are in Taiwan, requiring no submarine cables, are also broken. This is where the Trombone Effect comes in.

🏪 The Convenience Store Story

There’s a 7-Eleven on your street corner. You want to buy a bottle of water.

Normally: 🏠 → 🚶 30-second walk → 🏪 Done!

It’s like connecting to a server in Taiwan from Taiwan, data doesn’t need to cross the ocean, it stays on the island.

The convenience store analogy explains the Trombone Effect. Server is in Taiwan, you’re in Taiwan, data transfers directly within the island. As simple as walking to your corner 7-Eleven.

But Some ISPs Say…

"No! You can't just go to the one on your corner!"

Some ISPs dictate this route:

🏠 Your home
→ ✈️ First, fly to Tokyo
→ 🏪 Check out at a Tokyo 7-Eleven
→ ✈️ Fly back to Taiwan
→ 🏠 Get your water

All for a bottle of water available on your street corner 🤦

Your request is forced overseas and back. The server is right next to you, but your ISP’s routing configuration sends the traffic to Japan or Hong Kong before looping it back, absurd indeed.

Why Do Some ISPs Route This Way?

Because Taiwan’s ISPs don’t “shake hands” locally.

🤝 Peering: two providers agree, "your users can directly reach my servers"

🏢 Internet Exchange: a place where everyone comes to shake hands

Problem: some Taiwan ISPs aren't keen on shaking hands with others
or they share very little traffic

Explaining peering and Internet Exchange concepts. “Handshake” as an analogy for peering. TPIX is one of Taiwan’s internet exchange points, in theory, ISPs can directly exchange traffic there without routing overseas. But in practice, many ISPs (especially large ones) refuse to peer at TPIX, believing their network is big enough not to need to “shake hands” with smaller ones, or they show up but only open minimal bandwidth.

You Don’t Notice Under Normal Conditions

The detour through Tokyo only adds 20–30 milliseconds, you wouldn’t notice the difference.

So some ISPs think: “Users won’t notice anyway, why spend money on local peering?”

Until the cables go down: that overseas detour is now jammed

Your bottle of water is stuck in a queue on the Tokyo airport runway

Result: Server Right Next to You, but You Can’t Connect

📍 Server location

Taipei, Neihu

10 km from you

📍 Actual route your data takes

Taipei → Tokyo → Taipei

A 4,000 km detour

International congestion → detour jammed → you can't reach a server 10 km away

This is tromboning 🎺, the “trombone effect”: data loops around like the slide of a trombone.

Two Main Bottlenecks of This Phase

❶ Massive Gridlock

50% capacity ≠ 50% speed
Usable bandwidth may drop to just 15–20%

❷ Massive Detours

Insufficient domestic peering
Domestic traffic forced overseas
Even local servers affected

These two problems combined: “having internet” may not mean “usable internet.”

Summarizing the two core concepts of this phase. Congestion collapse: the nonlinear relationship between physical capacity and actual usable bandwidth. Trombone Effect: routing policies causing traffic that shouldn’t cross the ocean to also suffer. Together, they create “zombie internet”, looks alive, practically unusable.

But It May Get Even Worse…

The services still working, maybe Google Search occasionally returns results, some web pages are still viewable, they’re still alive possibly because of “caching”: copies previously stored in Taiwan that still work temporarily.

But caches have expiration dates…

When they expire, services may break one by one ⏳

Many services still functioning are relying on CDN caches. Caches have TTLs (time-to-live); once expired, they must fetch fresh data from overseas origin servers. But with submarine cable congestion, the fetch fails → cache expires → service goes down. This pattern of “gradual degradation” is explained in detail in the next phase.

30–60 min

Phase 3: It Was Just Working, Why Is It Broken Again?

Entering Phase 3. Congestion has stabilized, ISPs have started traffic management. But people notice a peculiar phenomenon: things that were working start breaking one by one. This phase explains three mechanisms: CDN cache expiry, Auth Token expiry, and DNS cache expiry. The “gradual degradation” caused by these three mechanisms is more dangerous than total disconnection, because it makes it impossible to pinpoint where the problem lies.

What You Experience

Google Drive was working a moment ago, now it’s stuck
News sites show text but all images are gone
LINE may crash and you can’t log back in
Banking app asks you to re-enter your password, then spins forever

Not everything breaks at once, they break one by one, seemingly at random.

This kind of “gradual failure” is the most confusing. Total disconnection actually lets people know “the internet is down” and prompts them to find alternatives. But when things break one at a time, some still working, some not, people keep retrying, wasting time, and growing more anxious. Next we explain why things “break one by one.” The answer: three different “expiration timers” are all counting down simultaneously.

Back to the Convenience Store

Your neighborhood 7-Eleven 🏪, the shelves have “copies” of drinks, bento boxes, and snacks.

Where do these products come from? Overseas warehouses 🚢, the 7-Eleven doesn’t make anything; it stocks goods from warehouses and puts them on shelves for you.

The digital world works the same way. CDN is your neighborhood’s digital convenience store (Content Delivery Network).

CDN = Content Delivery Network. Companies like Cloudflare, Akamai, and CloudFront have “edge nodes” in Taiwan. These nodes are like convenience stores: they copy content from overseas servers and store it locally in Taiwan, so users don’t have to fetch from overseas every time. The web page images, CSS, and JavaScript files you browse often come from CDN nodes in Taiwan.

Expiration Date: TTL

Time To Live

Convenience store bento boxes have expiration dates, once expired, they can’t be sold and must be restocked from the warehouse.

CDN caches have a similar expiration mechanism called TTL (Time To Live: how long this copy remains valid).

TTL might be 5 minutes or 24 hours, every website and every file has different settings.

For the first 30 minutes, most caches haven't expired yet, so things "still work." Now, expiration dates are starting to hit one by one.

TTL is set by the server, telling the CDN “how long this copy can be used.” A news site’s homepage images might have a TTL of just 5 minutes (needs real-time updates). A jQuery library might have a TTL of 1 year (rarely changes). In the first 30 minutes after the cable break, most caches are still within their validity period, so users feel things are “okay.” But as time passes, various caches’ TTLs expire one by one, and problems start appearing.

The Convenience Store Can’t Restock

Bento boxes on the shelf have expired → time to restock from the warehouse.

But the road to the warehouse is jammed 🚛💨

(International traffic congestion = extremely slow international connections)

The restocking truck has departed… but is stuck in traffic and can’t get back. The CDN requests fresh data from the overseas origin server → timeout → failure.

Expired cache + can't restock = empty shelves

When a CDN cache’s TTL expires, the CDN node sends a revalidation request to the overseas “origin server.” Normally this takes just milliseconds. But now international connections are congested, the request either times out or responds extremely slowly. The CDN can’t get new data, so it can’t continue serving content; users see a loading failure.

Why Can Some Things Load but Not Others?

✅ Still viewable

Popular YouTube videos
Commonly used website CSS/JS
News images everyone's viewing

→ Cache recently refreshed, TTL not yet expired

❌ Can't view

Niche pages, old articles
Documents you haven't opened in a while
Real-time content with short TTLs

→ Cache expired, restock failed

This is why some parts of the same website work while others don’t, leading people to think the site is broken, when really it’s just different cache expiration times.

This explains why users feel the failures are “random.” On the same website, HTML text might have a 24-hour cache TTL (still valid), but images might have just a 1-hour TTL (already expired). So you see text appearing but all images blank, a bizarre sight. Content accessed by more people stays “fresher” because restocking is constantly triggered. Niche content is the opposite, the cache has likely expired long ago.

What Is an Auth Token?

Imagine going to an amusement park 🎢

At the entrance, you buy a ticket and verify your identity, then a staff member stamps your hand with a stamp.

Using the amusement park analogy to explain Auth Tokens. This concept is unfamiliar to non-technical audiences, but it’s key to understanding “why apps log you out one by one.”

The Stamp on Your Hand = Auth Token

With the stamp, you can:

Ride the roller coaster 🎢, show the staff your stamp ✓
Ride the carousel 🎠, show stamp ✓
Buy park food 🍔, show stamp ✓

No need to re-queue, re-purchase tickets, or re-verify your identity each time. The stamp represents “this person has already been verified.”

An Auth Token is that stamp on your hand. After logging into Google, your browser receives a “stamp”, then opening Gmail, Drive, or YouTube doesn’t require logging in again.

Auth Token is this “stamp.” You log into Google once, and your browser gets a token. Every subsequent request to Gmail, Google Drive, or YouTube includes this token. The server sees the token and knows “this is an authenticated user” without asking for your password each time.

But the Stamp Fades

The amusement park’s stamp uses special ink, after 15 minutes to 1 hour, the stamp fades and becomes invisible.

Why not use permanent ink?

🔒 If someone copies your stamp (token stolen)

Fading ink → the thief can use it for 15 minutes at most

Permanent ink → the thief can impersonate you forever

So tokens are intentionally designed to expire: it’s a security mechanism.

Tokens being short-lived is a deliberate security decision. If a token were valid forever, once stolen (e.g., via XSS attack, man-in-the-middle attack), the attacker could impersonate you permanently. Short-lived tokens limit the damage of theft: even if stolen, it expires in 15 minutes. It’s like a credit card expiration date, not for your convenience, but to limit the risk of fraud.

Stamp Faded? Go Back to the Ticket Booth

Stamp faded → walk back to the entrance ticket booth 🎫, show your season pass, staff re-stamps your hand. The whole process takes seconds; you barely notice.

Normally, this is a total non-issue, the app automatically “re-stamps” you in the background without you ever noticing.

But… what if the ticket booth is on the other side of the ocean?

Under normal conditions, the “re-authentication” after token expiry happens automatically in the background. The browser or app uses a refresh token (like a season pass) to request a new access token from the authentication server. The entire process takes a few hundred milliseconds, users are completely unaware. But the critical question is: where is the authentication server?

The Ticket Booth Is Across the Ocean

Google’s authentication server is likely in 🇺🇸 the US
LINE’s authentication server is likely in 🇯🇵 Japan
Microsoft’s authentication server is likely in 🇺🇸 the US

Your stamp faded → you may need to cross the ocean to get re-stamped.

But international traffic is congested = that route is jammed 🚗🚗🚗

The re-stamp request was sent… but the reply can’t get back, waited 30 seconds → timeout → failed.

You've been logged out. And you can't log back in.

This is the core Auth Token problem during a submarine cable event. Google’s OAuth authentication servers are primarily in the US (accounts.google.com resolves to US IPs). LINE’s authentication goes through Japanese servers. Microsoft’s Azure AD is also in the US. When tokens expire and the app tries to re-authenticate with these overseas servers, the international connection is congested, requests time out, and you get logged out. And the login page itself also needs to connect to overseas servers, so even “logging back in” is impossible.

Everyone Gets Logged Out at Different Times

⏱️ 20 min after cable break: Google Drive stamp may have faded → possibly logged out
⏱️ 35 min after: LINE stamp may have faded → may crash and can't log back in
⏱️ 45 min after: Online banking stamp has faded → asks to re-login → fails
⏱️ 50 min after: Company Slack stamp may have faded → possibly disconnected entirely

This is why it seems "completely random", because each app's stamp fades at a different time.

Each service has a different token validity period: Google is typically 1 hour, some banking apps 15 minutes. And each user logged in at a different time, so tokens expire at different times. This creates the chaotic “gradual failure” scenario: your colleague’s Google Drive still works (they just logged in), yours doesn’t (your token just expired). Everyone asks each other “is yours working?” and gets different answers, even more confusing.

The True Face of a Token

Technically, a token looks like this:

  eyJhbGciOiJSUzI1NiJ9.eyJ1c2VyIjoi5bCP5piOIiwic2NvcGUiOiJkcml2ZSIsImV4cCI6MTcxMTEyMzQ1Nn0.SflKxwRJSMeKKF2QT4fw

This is called a JWT (JSON Web Token), containing:

👤 Who you are

user: Xiao-Ming

🔑 What you can do

scope: drive

⏰ When it expires

exp: 1 hr

The last segment is a digital signature: prevents forgery, only the server can generate it.

JWT is the most common token format today. It has three parts (separated by .): header (algorithm), payload (content), signature. The middle payload section is base64-encoded, containing JSON data. The key part is the final signature: it’s signed with the server’s private key, so nobody can forge it. When the server receives a token, verifying the signature confirms whether it issued the token.

The Life of a Token

1️⃣ Login: enter username & password → server gives you two things

　　Access Token (entry stamp) valid for 15 min–1 hour

　　Refresh Token (season pass) valid for days–weeks

2️⃣ In use: every action carries the Access Token

　　Server sees the stamp and lets you through, no need to verify password each time

3️⃣ Stamp fades: Access Token expires → automatically renewed using Refresh Token

　　Done automatically in the background, you never notice

4️⃣ Season pass also expires: Refresh Token expires too → must re-enter username & password

　　This is why you occasionally get asked to "log in again"

The standard OAuth 2.0 flow. Access Token is short-lived (like the stamp on your hand), Refresh Token is long-lived (like a season pass). Normally, when the Access Token expires, the app automatically uses the Refresh Token to get a new Access Token from the server. This entire process happens in the background, users notice nothing. Only when the Refresh Token also expires (typically days to weeks) are you asked to re-enter your credentials.

Why Not Issue a Permanent Pass?

🔓 If tokens were permanent

Stolen → attacker impersonates you forever

Permissions changed → old token still has old permissions

Left the company → token still works

🔒 Tokens expire periodically

Stolen → invalid in 15 minutes at most

Permissions changed → updated at next renewal

Left the company → token naturally expires

Token expiration isn’t a design flaw, it’s a security mechanism, like periodically changing door lock codes: inconvenient, but more secure.

This is the fundamental trade-off between security and convenience. A permanent token is like a key that never gets changed, convenient, but once copied, you’re done. Short-lived tokens are like periodically changed passcodes, annoying, but damage from a breach is limited. Under normal network conditions, the trade-off makes sense: re-authentication takes just a few hundred milliseconds, invisible to users. But during a submarine cable event, the “re-authentication” step suddenly becomes a fatal weakness.

The Chain Reaction During a Cable Break

Access Token expires

App may attempt to use Refresh Token in the background for a new one

Refresh request possibly sent to overseas auth server

But international connection is congested… waiting 10 sec, 20 sec…

Timeout failure ✗

App determines "authentication invalid" → possibly forces logout

But the login page itself may need to connect to overseas servers → also times out ✗

Logged out, and possibly can't log back in.

This is a cascading failure:

Access Token expires (normal mechanism)
Refresh request times out due to congestion (abnormal)
App determines authentication is invalid, forces logout (normal response)
User tries to log back in, but the login flow itself also requires international connectivity (fatal weakness)

Especially for OAuth login flows, the “Sign in with Google” button connects to accounts.google.com, and that server is in the US. So you can’t even open the login page.

Your Apps May Be Logging Out One by One

t+0 min　International traffic drops: all Token timers start counting down
t+15 min　Banking token expires → logged out
t+25 min　Slack token expires → possibly offline
t+35 min　LINE needs re-verification → possibly fails
t+45 min　Google Drive token expires → possibly can't access files
t+60 min　Possibly almost all authenticated services have failed

A “single disconnection” is unlikely to happen, it’s more like a slow-motion mass logout. Different people, different apps, different times: it looks completely random.

This is a timeline summary of the entire auth token story. The key takeaway: it’s not as simple as “the internet went down.” There’s an invisible countdown timer running inside every app, and the moment it hits zero, that app “dies.” And because every service has a different token validity period and every person logged in at a different time, the whole process looks completely random and without pattern.

Next Up: DNS

CDN cache expires → content disappears. Auth Token expires → logged out.

There's a third thing also counting down…

And if this one breaks, you can’t even find where the website is.

The previous two problems were “can’t get content” and “can’t authenticate identity.” The third is even more fundamental: “can’t even look up the address.” So we need to explain from the very basics.

What Is DNS? The Internet’s Phone Book

You type google.com into your browser, but your computer doesn’t understand “google.com.”

Computers only understand numeric addresses: 142.250.185.46, this is called an IP address, like a phone number, every server has one.

DNS = a phone book 📒, translating “names” to “phone numbers” (google.com → 142.250.185.46).

Without this phone book, even knowing someone's name doesn't let you call them.

DNS = Domain Name System. We use domain names to browse the internet, but computers communicate using IP addresses. DNS is the translation layer in between, converting human-readable names into computer-readable numbers. Without DNS, you’d have to memorize every website’s IP address to go online, like having to memorize everyone’s phone number without a contact list.

How Does DNS Lookup Work? Like Calling Directory Assistance

Your phone wants to find google.com’s phone number:

1️⃣ First, check your own contacts (local cache)

If you've looked it up before, use it directly, no need to ask anyone

2️⃣ Not there → call your ISP's directory service (DNS resolver)

Your ISP has a server dedicated to looking up numbers for you

3️⃣ ISP doesn't have it either → ask all the way up to "headquarters"

Root Server → .com administrator → google.com's authoritative server

4️⃣ Found it! Save the result in your contacts for next time

This is "DNS caching": remember the result to avoid calling every time

DNS lookup hierarchy:

Local cache (your device remembers previous lookups)
ISP’s DNS resolver (like 8.8.8.8 or your ISP’s DNS)
Root servers → TLD servers (managing .com) → authoritative servers (google.com’s administrator)

Normally, this entire process takes just tens of milliseconds. And results are cached at each level, so next time you don’t have to start from scratch. But caches also have expiration dates.

DNS Cache Also Has an Expiration Date

The phone numbers in your contacts also “expire”, google.com’s TTL might be set to 300 seconds (5 minutes), some .tw websites might be set to 3600 seconds (1 hour).

Why not remember permanently? Because servers might move (change IP), do load balancing, or perform failover. If you always use the old number, you might be calling a disconnected line.

So DNS caches also have TTL: once expired, you must look up the number again, normally takes tens of milliseconds, completely unnoticeable.

DNS record TTLs are set by website administrators. Large websites typically have short TTLs (minutes) because they need to frequently adjust traffic distribution. Small websites may have longer TTLs (hours to a day). Under normal conditions, DNS re-lookup is very fast, but during a submarine cable event, many websites’ authoritative DNS servers are overseas, making re-lookups travel through congested international connections.

DNS Cache Expires = Can’t Find the Address

Imagine a website service.gov.tw with its server right in Taipei 🏢.

Your device looked it up before, your contacts have its IP → connection works, fast ✓

But the DNS cache has expired: time to look up the number again. Where’s the authoritative DNS server? Possibly in the US (e.g., AWS Route 53)

The lookup call can't get through → you can't find the address, the server is just 10 km away, but you can't find it.

The server isn’t down, the internet isn’t cut, you’ve just forgotten the address, and you can’t ask anyone.

This is the most ironic DNS cache scenario: a .tw website, server physically in Taiwan, data in Taiwan, no international connection needed at all. But its authoritative DNS server uses AWS Route 53 (in the US). When your DNS cache expires and you need to re-query, the query request has to reach the US, through congested submarine cables, and then times out. Result: a completely domestic service, unreachable because the DNS can’t be resolved. This is the concept of “dependency chains”, on the surface it’s a domestic service, but it hides overseas dependencies.

1–6 hr

Phase 4 and Beyond: Control Plane Depends on Overseas

Entering Phase 4. The cable break happened over an hour ago. BGP reconverged long ago, congestion has stabilized, and the “gradual degradation” from various cache and token expirations has mostly run its course. But people notice a new phenomenon: some things are starting to recover, while others are completely dead. This phase explains two things: (1) ISPs begin manual traffic management, (2) cloud “control planes” depend on overseas infrastructure. Together, they create a new dividing line: purely domestic services come back to life; services with an overseas “brain” stay dead.

What You Experience

LINE text messages: possibly working again! ✅
Some previously visited web pages: possibly viewable
YouTube: possibly watchable, but maybe only at 144p pixelated quality
Instagram: possibly text only, all images are gray boxes 🖼️❌
Logging into any SaaS tool: possibly spinning, failing
AWS / GCP admin console: possibly completely inaccessible

A new dividing line emerges, what works vs. what doesn’t depends on where the service’s “brain” is located.

The key feeling at this phase is “unfairness”: why are some things recovering while others are getting worse? LINE text recovers because ISPs start traffic management, giving messages high priority. SaaS and cloud admin consoles are completely dead because their “control planes” are overseas. Next, we explain in two parts: (1) what ISPs are doing, (2) the “brain overseas” problem of cloud services.

What Are ISPs Doing Behind the Scenes?

Imagine an emergency room 🏥

During a major disaster, a surge of patients floods the ER, doctors are limited, can’t treat everyone at once, so the ER uses triage.

Using the ER analogy to explain ISP traffic engineering. After the cable break, international bandwidth is halved, but traffic demand hasn’t decreased, like a surge of patients but not enough doctors. ISP network engineers must manually intervene to decide which traffic gets priority. This is the internet’s version of “triage.”

Triage: Who Gets Treated First?

🔴 Likely highest priority

DNS queries
Government websites
Instant messaging (LINE text)
Financial transactions

🟡 Likely secondary priority

General web browsing
Email
Low-resolution streaming

🟢 Likely deferrable

YouTube HD
Instagram images/video
Software updates
Cloud backups

ISP engineers may manually intervene, deciding whose packets get priority, this is why some things “recover” while others get even slower.

ISP traffic management (traffic engineering) is mostly automated under normal conditions. But during a submarine cable event, engineers manually intervene to set QoS (Quality of Service) rules. DNS and government websites get the highest priority because DNS is the foundation of all internet services. Instant messaging (LINE text) has small traffic volume but high public impact, so it also gets priority. YouTube and Instagram images/video have massive traffic volumes (high percentage of total traffic) and get deprioritized. This is why you see YouTube quality plummet and Instagram show only text without images.

Why Might LINE Text Be Working Again?

1️⃣ LINE text messages = relatively small packets, one text message is about 1 KB, one Instagram photo is about 2,000 KB, a 2,000x difference.

2️⃣ ISPs may have listed messaging as high priority, small packets + local routing + high priority = can possibly squeeze through ✅

Instagram images? Large packets + overseas source + possibly deprioritized = possibly spinning 🖼️

LINE text recovery is due to three compounding factors: (1) Extremely small packets, text messages use negligible data; even under extreme congestion they can squeeze through. (2) LINE has peering connections at TPIX (Taiwan Internet Exchange), meaning much of LINE’s text messaging actually routes domestically, not even needing submarine cables. (3) ISP traffic management lists instant messaging as high priority, ranked first in triage. All three factors combined, LINE text messages recover. By contrast, Instagram photos are often several MB, sourced overseas, and deprioritized, hence only gray boxes.

Your Internet May Not Be Broken, It May Be “Managed”

🚦 ISP engineers = traffic officers at an intersection

Normal times: green light, all cars pass, you don’t even notice the traffic officer.

Crisis times: officer steps out to direct 🖐️, “Ambulance goes first! Bus can pass! Private cars wait!”

Your YouTube may not be “broken”, it might have been asked to yield to more important traffic.

The key point here is understanding: the “partial recovery” you’re experiencing isn’t random, it’s the deliberate result of ISP engineer decisions. ISPs have the ability to differentiate types of traffic and set priorities. You never notice normally because there’s enough bandwidth for everyone to pass. But when bandwidth tightens, ISPs’ “choices” directly determine what you can and can’t use.

What Does This Mean? Something You Should Know

ISPs have the capability to classify and manage traffic, they know which packets go where and what type they are

This means ISPs' everyday routing decisions are also "choices", choosing to route your traffic overseas and back instead of peering locally

If ISPs can choose who to save in a crisis, it means ISPs are also choosing who to sacrifice in normal times

This is the core insight of the ISP traffic management section. Everyone just saw that ISPs have the ability to classify and prioritize traffic during a crisis, which means ISPs also have this ability during normal times. The Trombone Effect from Phase 2, where ISPs route local traffic to Tokyo and back, isn’t a technical limitation, it’s a cost-driven choice. Not peering locally at TPIX is also a choice. This section connects Phase 2’s critique with Phase 4’s observation: ISPs aren’t passive pipes, they’re actors with capability, choices, and accountability.

Next: The Cloud Problem

LINE text may be back, some web pages may be viewable, but SaaS tools and cloud services may be completely dead.

To understand why, we first need to understand one thing: what exactly is “the cloud”? ☁️🤔

Transitioning to the cloud control plane section. Many people’s understanding of “the cloud” stays at a vague level, “data is stored on the cloud.” We need to explain “the cloud” clearly before we can explain why “cloud in Taiwan” ≠ safe.

“The Cloud” Is Actually… Someone Else’s Computer

You’ve heard “data is stored in the cloud” ☁️, sounds light, abstract, floating in the sky.

The truth: your data is stored on someone else’s computer. That computer sits in a massive building with air conditioning, security, and backup generators. That building is called a “data center.”

Taiwan has such buildings 🏢, both AWS and GCP have data centers in Taiwan. Your data does physically reside on Taiwan’s soil ✓

First, breaking the abstraction of “the cloud.” Many people hear “cloud” and think data floats in some ethereal space. But the cloud is someone else’s computer, housed in large data centers. AWS launched a Taiwan region in 2022 (with data center in Banqiao, New Taipei). GCP also has a data center in Changhua. So “data is in Taiwan” is physically true, but what follows explains why that’s not enough.

The Factory and Headquarters

Imagine a multinational corporation that built a factory in Taiwan:

🏭 Taiwan factory

Produces goods (stores your files)

Ships to customers (responds to your requests)

Warehouse has raw materials (your data)

→ This is the "Data Plane"

🏢 US headquarters

Issues employee badges (identity auth, IAM)

Approves budgets (resource provisioning)

Signs contracts (SSL certificates)

→ This is the "Control Plane"

Factory is in Taiwan ✓　But every important decision requires calling headquarters

Cloud services split into two layers: (1) Data Plane: where data is actually stored and processed, this is in Taiwan. (2) Control Plane: management, authentication, authorization, provisioning, this is usually in the US. Many of AWS’s control plane core functions are concentrated in us-east-1 (Virginia). GCP’s global control plane has a similar centralized design. The factory can produce goods, but without headquarters’ authorization, the factory can’t open its doors, can’t ship, can’t do anything.

Factory in Taiwan, but the Key May Be in the US

🔑 Employee needs to enter the factory (you need to log into AWS) → may need to verify identity with US headquarters (IAM authentication) → request travels via submarine cable to Virginia → timeout

📋 Factory needs to ship (website needs to renew security certificate) → may need US headquarters to sign the contract (SSL certificate validation) → request travels via submarine cable → timeout → HTTPS connection fails

📞 Customer wants the factory’s address (DNS resolution) → address book may be in the US (Route 53 is in us-east-1) → query travels via submarine cable → timeout → can’t find the factory

Factory intact, materials stocked, machines running, but the doors just won't open

Three concrete scenarios illustrating control plane dependency impacts: (1) IAM (Identity and Access Management), AWS’s identity verification system. Logging into the AWS Console or API calls all require IAM verification. IAM’s core service is in us-east-1. During submarine cable congestion, verification requests time out, and you can’t log in. (2) SSL/TLS certificates, HTTPS connections require valid security certificates. Certificate verification and renewal need to connect to overseas CAs (Certificate Authorities) or AWS Certificate Manager (also in us-east-1). Certificate expires and can’t renew → HTTPS connection can’t be established. (3) Route 53, AWS’s DNS service. If your website uses Route 53 for DNS, your “address book” is in the US. DNS query timeout → can’t find your website. The common conclusion across all three scenarios: your data and servers are in Taiwan, but “the key to open the door” is in the US.

Your Data Is Right Here, but You Don’t Have “Authorization” to Open It

🔐

Your Google Drive files may physically reside in GCP's Changhua data center

But you just can't open them

Because you may need a US server to confirm authorization

It’s like putting a safe in your house but leaving the key at a bank overseas 🏦, the bank is operating normally, but you can’t make an international call anymore.

The safe/key analogy is very intuitive: if the key isn’t at home but overseas, you wouldn’t think “the safe is at home so it’s secure.” But this is exactly the current state of most Taiwanese enterprises’ cloud architecture, data in Taiwan, but authorization mechanisms overseas. The December 2021 AWS us-east-1 outage was a precedent: other physically healthy AWS regions were also affected because IAM, Route 53, and other control plane services are concentrated in us-east-1. That incident wasn’t a submarine cable issue, it was us-east-1 itself having problems, but the effect was identical: your region is fine, but the control plane is down, so you go down too.

“Cloud in Taiwan” ≠ Safe

🏭

Factory in Taiwan

✓

🔑

Key in the US

✗

📞

Phone line jammed

✗

“We use Taiwan’s AWS/GCP” may ≠ “our services will still work when international traffic drops significantly”

This is the core conclusion of the cloud control plane section. Many enterprises and government agencies, when answering “is your service resilient?”, say “we use the Taiwan AWS region” or “our GCP data center is in Changhua.” But that only means “the factory is in Taiwan”, not “the key is also in Taiwan.” If the control plane depends on overseas infrastructure, then when submarine cables are severed, your service goes down with them. “Taiwan cloud” creates a false sense of security, this is the most critical misconception that needs to be shattered.

Winners: Truly Domestic-Only Services

In this simulation, some services may be completely unaffected.

✅ Services that survive look like this:

Server in Taiwan

Authentication (Auth) in Taiwan

Authoritative DNS server in Taiwan

CDN origin in Taiwan

The entire dependency chain stays on the island → submarine cable status is irrelevant

The emphasis here: surviving a submarine cable event isn’t just about “having a server in Taiwan.” Your entire dependency chain, server, authentication, DNS, CDN origin, must all be in Taiwan. Any single link depending on overseas infrastructure is a weak point. Services completely unaffected in this simulation are those that “chose” to make every layer domestically self-sufficient. That’s not coincidence, it’s a deliberate architectural decision.

What’s the Difference? One Table

	Server	Auth	DNS	CDN Origin	During Cable Break
Fully domestic stack	🟢 Taiwan	🟢 Taiwan	🟢 Taiwan	🟢 Taiwan	✅ Normal operation
Taiwan cloud	🟢 Taiwan	🔴 US	🔴 US	🟢 Taiwan	⚠️ Runs but can’t log in
Fully overseas	🔴 Overseas	🔴 Overseas	🔴 Overseas	🔴 Overseas	❌ Completely down

Most Taiwanese enterprise services fall in the middle row, appears to be in Taiwan, but dependencies are overseas.

This table makes the differences across three architectures immediately clear. The focus is the middle row, “Taiwan cloud.” Most Taiwanese enterprise and government services fall here: server indeed in Taiwan (AWS Taiwan region, GCP Changhua), but authentication, DNS, and even some CDN logic depend on overseas control planes. This gives the illusion of “being in Taiwan,” but during a submarine cable event, it still breaks. This is also the most dangerous state, because until something goes wrong, nobody examines these hidden dependencies.

Is It a Technical Limitation?

Those services that survived didn’t get lucky, someone chose to spend extra time, extra money, and make every layer domestically self-sufficient.

“If the submarine cables broke, would our services still work?”

This is the most important message of this section: resilience is a choice, not fate. The default configuration of AWS and GCP naturally depends on overseas control planes, because these are global services, that’s a reasonable default. But if you operate critical services in Taiwan, you need to proactively change that default. Most enterprises haven’t done so, not because they can’t, but because nobody asked the question. This is also why we need policy and regulations to drive change, because relying on corporate self-awareness alone isn’t enough.

Simulation Recap

Phase	Your Experience	Possible Cause
0–5 min	VoIP calls drop	BGP reconvergence + call control server in Japan
5–30 min	Everything slows, freezes	Congestion collapse + Trombone Effect
30–60 min	Services drop one by one, logouts	Cache TTL expiry, Token expiry, DNS failure
1–6 hr	Cloud admin consoles all down	Control plane depends on overseas

Building the complete causal chain: experience → technical cause → decision-makers. The point is to show that no failure is a “natural phenomenon”, every one is the result of some organization’s engineering or policy choices.

Simulation Complete

All stakeholders need to conduct a network outage drill.

🤔 Questions for Everyone

In the scenario we just walked through, would government websites (gov.tw) hold up?
http://poslab.info/slide/20260325

How are the submarine cables doing right now?
https://drive.google.com/file/d/1n9mbFNVeukMt3g_ywP8ne9366JWWhnT5/view

Digital Resilience Forum: Subsea Cables and Network Infrastructure under Geopolitical Pressure

2026-03-25T00:00:00+08:00

What happens when subsea cables go dark? Are subsea cables a false issue?

The subsea cables that connect the internet have recently become a major focus. Surrounded by sea, Taiwan is especially sensitive and vulnerable to changes affecting subsea cables, and this vulnerability is even more pronounced amid unstable geopolitics.

Registration link: Google Form

Instead of simply worrying, come learn more!! The first { Digital Resilience Forum } will take a close look at every facet of the subsea cable issue. Alongside presentations on two technical projects, the “Taiwan Subsea Cable Dynamic Map” and “Digital Service Resilience Testing,” which will help everyone understand what exactly we should worry about when it comes to subsea cables, the forum will examine their impact from the perspectives of policy, social security, and civic participation.

This is CRC’s first public event. Register now and join us in identifying the problems so that we can find ways to respond.

ℹ️Date: Wednesday, March 25 ℹ️Time: 1:30–17:00 (check-in at 1:00) ℹ️Venue: Impact Hub 2F (No. 2, Section 3, Chongqing South Road, Zhongzheng District, Taipei City)

Seating is limited; please register here: Google Form

Presentation Slides: Digital Resilience Forum — Subsea Cables and Network Infrastructure under Geopolitical Pressure

2026-03-25T00:00:00+08:00

What happens when subsea cables go dark? Are subsea cables a false issue?

The subsea cables that connect the internet have recently become a major focus. Surrounded by sea, Taiwan is especially sensitive and vulnerable to changes affecting subsea cables, and this vulnerability is even more pronounced amid unstable geopolitics.

The first { Digital Resilience Forum } examined every facet of the subsea cable issue. Alongside presentations on two technical projects, the “Taiwan Subsea Cable Dynamic Map” and “Digital Service Resilience Testing,” which helped everyone understand what exactly we should worry about when it comes to subsea cables, the forum examined their impact from the perspectives of policy, social security, and civic participation.

CHENG PENG’s presentation slides: https://crcolab.github.io/crccolab-mar-25-2026-internetional-network-degraded-simulation/
Li-Heng Yu’s presentation slides: https://drive.google.com/file/d/1n9mbFNVeukMt3g_ywP8ne9366JWWhnT5/view
Irvin Chen’s presentation slides: http://poslab.info/slide/20260325

ℹ️Date: Wednesday, March 25 ℹ️Time: 1:30–17:00 (check-in at 1:00) ℹ️Venue: Impact Hub 2F (No. 2, Section 3, Chongqing South Road, Zhongzheng District, Taipei City)