An unsuccessful technical solution cost the organizers of the Coordination Council voting dearly

Illustrative photo: Nasha Niva

During the elections to the Coordination Council, large-scale DDoS attacks on the initially chosen platform were reported. As a result, the voting was moved to another platform.

We wondered why this happened. And most importantly: why it was not possible to conduct the voting there, while many independent initiatives calmly operate on a similar platform.

The organizers of the CC elections reported a colossal number of requests: 1.3 billion.

Initially, the voting was organized on the storage.googleapis.com platform. It's a cheap, reliable Google storage with an infinite capacity, used by companies to store archives, data, images, and files. Information is only retrieved from this storage upon request; it has no other functionality. Therefore, Google charges for the volume of outgoing traffic from the address and also the number of requests to it.

In its usage instructions, Google explicitly warns that the protection capabilities for such an address are minimal and essentially come down to allowing information to be retrieved from the bucket only from permitted IPs, cutting off all others. Google advises clients to make bucket addresses unguessable. Meanwhile, the address of the CC voting platform was shared publicly.

Google also warns that as the number of requests to a bucket increases, capacity will gradually increase to satisfy all requests. But these requests will be charged. There is no possibility to set a budget limit in this case.

Thus, with mass requests to it, for example, during a DDoS attack, the address owner's bill from Google will accordingly increase — especially given that a significant amount of information is being served from this bucket. 

The advantage of a Google bucket is that such a link cannot be blocked in Belarus — otherwise, a lot of services important for the economy would collapse. Additionally, it is relatively secure: the provider sees nothing beyond storage.googleapis.com/.

When other websites' buckets are DDoS'd — and they are DDoS'd regularly — access to them either doesn't stop, or stops only for a few minutes. Moreover, websites have configured their platforms so that such a DDoS attack costs its organizers much more than the bucket owners. This is because due to the negligible amount of information returned in response, the cost of the attack becomes disproportionately large relative to the damage inflicted. 

'The content of the bucket through our system is very small, as we serve a couple of kilobytes, not the entire page snapshot. Therefore, our costs during strong attacks do not increase as much as those of the attackers,' explained an IT engineer who set up such a system for one of the websites to Nasha Niva.

However, in the case of the Coordination Council voting, there is reason to believe that each transfer from the bucket at the address https://storage.googleapis.com/ccelect26/index.html/... was not fractions of kilobytes, but about 3.4 megabytes. At least, such a transfer was recorded when accessing the website https://rada2026.svaepeera.com, to which the voting moved after the attacks on the bucket.

We measured this transfer in the terminal:

index-DnQoUsja.js: 881 bytes
lib-BZRoH1pn.js: 2581282 bytes
index-CPW0kV3N.js: 802688 bytes

Simply put, the voting page was 'fat' — possibly overloaded with heavy scripts and not optimized.

This also leads to the conclusion that the owner of the bucket where the voting was initially deployed incurred losses. Possibly — large ones, on the order of tens of thousands of dollars.

Nasha Niva asked Pavel Liber, who assisted the Coordination Council in organizing the voting. 

'Since the expenses related to the attacks are not reimbursed to me from any money other than my own, I do not plan to disclose them,' Liber replied. 

He also explained that the voting website was intentionally distributed via a public Google bucket because, he believes, 'such a link is safer for accidental access from Belarus, as for telecom providers, the visibility of the Google domain is primary.'

'When we found that the attacks had high intensity and were capable of exceeding the daily limits of this bucket (at which point people see an error instead of the site), we switched to a regular site + Cloudflare and took the main hits there.

Liber also points out that 'the elections were postponed not because of a DDoS attack, but because changes were made to the technical specifications, and a commission representative was testing these changes, as a result of which the start date was postponed to May 12 at 12:00 — this was stated in the commission's public online stream'. 

A cybersecurity specialist with 20 years of experience, whom Nasha Niva consulted, believes otherwise. In his opinion, the technical solution used for the Coordination Council voting in 2026 was risky for various reasons and should no longer be used. 

Could the voting page have been made lighter? 'Maybe it's feasible. But that means doing everything yourself. And people most likely used ready-made libraries,' a Belarusian programmer working in Portugal told us.

• 6
• 6
• 2
• 13
• 5
• 5
• 0
• 1