Study of the causes of abnormal voting on the ROI website or the specifics of e-democracy in Russia
I have been watching the Russian Public Initiatives site for a long time, approximately since May 29, 2013 . Like other observers , I noticed anomalies in the course of voting for various initiatives. But it didn’t bother very few people, while anomalies led, according to our estimates, to an increase in the number of votes. Apparently, no one considered something bad if the next initiative gained 100,000 votes ahead of time. Everything changed when the anomalies began to slow down the vote.
It began on November 24 at 13:35 Moscow time. The vote count for the adoption of the initiative 9376 decreased by 2. Then another 1 and another 2. In the evening, the decrease in the counter value began to occur more and more often. Someone noticed this and informed the author of the initiative. From that moment, a thorough monitoring of the voting process began.
')
I will tell you about some of the strange voting that we (observers) have noticed over the past week. I will also try to make assumptions about the causes of some of them. There are few conclusions, because It is not always possible to obtain the necessary data on the voting process.
From the graphs it quickly became clear that at certain moments the change in the counter occurs more dramatically. Moreover, these moments are the same for each hour with an accuracy of a few seconds. For example, on our logs, the peaks of the increase in votes were observed on minutes 3, 9, 15, 21, 27, 33, 39, 45, 51, 57. A few days later, the minutes shifted by one (it became 4, 10, 16 ...) but in the interval of several hours they still fell in the given minute and second.
So, the probability of getting a voice depends on the specific minute. For some initiatives, this dependence is pronounced:
For some, weaker:
Somewhere almost invisible:
But the most interesting thing happens with the initiative " On criminal liability for the illegal enrichment of officials ." In it dependence is observed only to reduce the number of votes:
The main thing is that I wanted to find out: are the six-minute peaks on the counter the result of the external script's work with respect to the ROI, or is this the internal mechanism of the site (caching, error, malicious intent).
The possibility of voting by bots is very real. To log on to the ROI, an account is used on the “Gosuslugi” website. The requisites of access to public services can be stolen in the same way as VKontakte accounts. Even easier, because the State services do not take special measures to protect against unauthorized access. For example, they do not block accounts when entering a site from new locations.
Voting on the site takes place by sending a post-request to the address www.roi.ru/ajax/voting . Voting user is determined by cookies (SESSIONID). The initiative and the type of voting are set by the parameters of the POST request. Obviously, the number of requests to the server should be equal to the number of votes. We suggested that by reducing the data collection interval, the voices of individual users / bots should be visible. With voices outside regular peaks, recording data every two seconds is enough to split the majority of voices:
Packages of several negative votes cannot be divided by time. The group of votes is always added / subtracted simultaneously (within the error of a change of about 300 ms, related to the response time of the server and the processing of the request). The maximum group that could be observed consisted of 7 votes (decrease counter). The typical time of the POST request voting (/ ajax / voting /) is 300..350 ms. It is unlikely that 7 such fairly heavy requests can be performed from a remote server in a second and not allow a single failure in the entire history of observations.
How can this be?
- Requests can be executed from a nearby computer and deliberately run synchronously in several streams (which makes no sense if you want to show the natural course of the vote).
- Or the appearance of groups of voices is connected with the internal mechanisms of the ROI website .
Representatives of the ROI do not deny that they have some code that leads to the appearance of packages, but do not give a clear explanation. What internal mechanisms can give a picture with peaks on the graph of the increase in votes?
- counter caching
- replication lag when replicating the database according to the Master-Slave scheme
- something other
To test the influence of these factors, we began to run a vote and vote recall by a script, tracking the change in meter readings. There immediately arose a problem. There are three counters on the initiative page: the upper counter of the total number of votes, the lower counter of the total number of votes and the hour counter in the right column (it does not interest us yet).
When voting through the site, we saw that the total vote counters change immediately (up to page reload time) and synchronously. When voting with a script, only the upper counter changed. After a few minutes, the upper counter readings returned to the previous value. Moreover, the minutes and seconds of the counter rollback coincided with the minutes and seconds of abrupt changes in the counter! This means that the site has a mechanism that corrects the meter readings (counters) on a specific schedule. Probably, the same mechanism is responsible for the abrupt changes of the counters, since the time of change coincides with the schedule of its work.
It turned out that for the correct operation of the voting API, it is necessary to transfer not only the initiative id (petition_id), but also a certain decision_id unique for each initiative. If both parameters are transmitted, the bot's voice is taken into account immediately in both counters and does not disappear in a few minutes. The purpose of the decision_id is unknown to us.
Now you can try to deal with the nature of the internal mechanism that changes the meter readings. Let me remind you that we assumed the possibility of caching or delay in replicating the database. We began to run a vote "for" and the abolition of votes in the cycle every 30 seconds. Between voting and cancellation was from 5 to 20 seconds in different experiments. After each vote / withdrawal, a check of meter readings was launched. They always changed simultaneously. Hundreds of measurements were made at different times and on different initiatives. There has never been a case when the meters would not react to the voice. Example of issuing a script:
At the same time, the batch voices both arrived and continued to do:
How can caching affect only voices, but never affect verification voices?
We also noticed that a discontinuous change in the number of votes is not synchronous for two counters. The lower counter “catches up” the upper in about a minute. This behavior is not typical for normal voting through the site. This is more like a bot voting without the decision_id parameter with the difference that when voting without a decision_id, the increment of the upper counter is canceled, and in this case we see that the lower counter adjusts to the upper one:
At some point, it turned out that the domain www.roi.ru two IP look into the world.
At the moment, the reasons for the appearance of regular package additions and subtractions of votes are not clear to us. It looks more like an internal factor, but its nature remains a mystery. In the comments, please express your versions of what is happening (technical, not conspirological).
Recently, a good detailed analysis of voting schedules has appeared. Personally, I do not agree with all the conclusions of the author. For example, many conclusions are made with the assumption that the robot can vote perfectly simultaneously from several accounts. In reality, this is only possible if the robot is on the same server as the POI database.
ROI rolled out update:
- Now you can not recall the voice ;
- counters are updated not immediately after the vote, but once a minute.
Now you can not even make sure that your voice is taken into account ;
- the six-minute anomalies were turned off (in fact, this proves that they were not made by an outside robot, but by the ICs).
If disabling a callback is, on the whole, a positive thing, then meter caching is a strong blow to independent monitoring. However, polls have many more strange moments. Perhaps it is time to prepare the continuation of the post.
The head of the E-Democracy Foundation Ilya Massuh told about the project news . But it is somehow strange ... He writes that there used to be caching, although experimentally we could not find it. He writes that the withdrawal of the initiative to the top by auto-voting was a discovery for him, although this is not the case (the author of the spin-off initiative himself spammed all the ROIs with this information). This is explained by the fact that “all this activity occurred parallel to the process of improving the algorithms” (I translate: the light from Venus reflected from the upper layers of the atmosphere and caused an explosion of marsh gas). But now the algorithm has really improved : a cache has appeared, so within a minute you can do anything with your voice, no one will even know about it.
I propose to discuss a plan of action . It is important!
It began on November 24 at 13:35 Moscow time. The vote count for the adoption of the initiative 9376 decreased by 2. Then another 1 and another 2. In the evening, the decrease in the counter value began to occur more and more often. Someone noticed this and informed the author of the initiative. From that moment, a thorough monitoring of the voting process began.
')
I will tell you about some of the strange voting that we (observers) have noticed over the past week. I will also try to make assumptions about the causes of some of them. There are few conclusions, because It is not always possible to obtain the necessary data on the voting process.
From the graphs it quickly became clear that at certain moments the change in the counter occurs more dramatically. Moreover, these moments are the same for each hour with an accuracy of a few seconds. For example, on our logs, the peaks of the increase in votes were observed on minutes 3, 9, 15, 21, 27, 33, 39, 45, 51, 57. A few days later, the minutes shifted by one (it became 4, 10, 16 ...) but in the interval of several hours they still fell in the given minute and second.
So, the probability of getting a voice depends on the specific minute. For some initiatives, this dependence is pronounced:
For some, weaker:
Somewhere almost invisible:
But the most interesting thing happens with the initiative " On criminal liability for the illegal enrichment of officials ." In it dependence is observed only to reduce the number of votes:
The main thing is that I wanted to find out: are the six-minute peaks on the counter the result of the external script's work with respect to the ROI, or is this the internal mechanism of the site (caching, error, malicious intent).
The possibility of voting by bots is very real. To log on to the ROI, an account is used on the “Gosuslugi” website. The requisites of access to public services can be stolen in the same way as VKontakte accounts. Even easier, because the State services do not take special measures to protect against unauthorized access. For example, they do not block accounts when entering a site from new locations.
Voting on the site takes place by sending a post-request to the address www.roi.ru/ajax/voting . Voting user is determined by cookies (SESSIONID). The initiative and the type of voting are set by the parameters of the POST request. Obviously, the number of requests to the server should be equal to the number of votes. We suggested that by reducing the data collection interval, the voices of individual users / bots should be visible. With voices outside regular peaks, recording data every two seconds is enough to split the majority of voices:
Packages of several negative votes cannot be divided by time. The group of votes is always added / subtracted simultaneously (within the error of a change of about 300 ms, related to the response time of the server and the processing of the request). The maximum group that could be observed consisted of 7 votes (decrease counter). The typical time of the POST request voting (/ ajax / voting /) is 300..350 ms. It is unlikely that 7 such fairly heavy requests can be performed from a remote server in a second and not allow a single failure in the entire history of observations.
How can this be?
- Requests can be executed from a nearby computer and deliberately run synchronously in several streams (which makes no sense if you want to show the natural course of the vote).
- Or the appearance of groups of voices is connected with the internal mechanisms of the ROI website .
Representatives of the ROI do not deny that they have some code that leads to the appearance of packages, but do not give a clear explanation. What internal mechanisms can give a picture with peaks on the graph of the increase in votes?
- counter caching
- replication lag when replicating the database according to the Master-Slave scheme
- something other
To test the influence of these factors, we began to run a vote and vote recall by a script, tracking the change in meter readings. There immediately arose a problem. There are three counters on the initiative page: the upper counter of the total number of votes, the lower counter of the total number of votes and the hour counter in the right column (it does not interest us yet).
When voting through the site, we saw that the total vote counters change immediately (up to page reload time) and synchronously. When voting with a script, only the upper counter changed. After a few minutes, the upper counter readings returned to the previous value. Moreover, the minutes and seconds of the counter rollback coincided with the minutes and seconds of abrupt changes in the counter! This means that the site has a mechanism that corrects the meter readings (counters) on a specific schedule. Probably, the same mechanism is responsible for the abrupt changes of the counters, since the time of change coincides with the schedule of its work.
It turned out that for the correct operation of the voting API, it is necessary to transfer not only the initiative id (petition_id), but also a certain decision_id unique for each initiative. If both parameters are transmitted, the bot's voice is taken into account immediately in both counters and does not disappear in a few minutes. The purpose of the decision_id is unknown to us.
Now you can try to deal with the nature of the internal mechanism that changes the meter readings. Let me remind you that we assumed the possibility of caching or delay in replicating the database. We began to run a vote "for" and the abolition of votes in the cycle every 30 seconds. Between voting and cancellation was from 5 to 20 seconds in different experiments. After each vote / withdrawal, a check of meter readings was launched. They always changed simultaneously. Hundreds of measurements were made at different times and on different initiatives. There has never been a case when the meters would not react to the voice. Example of issuing a script:
refresh
200 72019 72019 2014-12-01 13:26:12
voting
200 success_affirmative 2014-12-01 13:26:16
refresh
200 72020 72020 2014-12-01 13:26:21
cancellation
200 success_reject 2014-12-01 13:27:05
refresh
200 72019 72019 2014-12-01 13:27:10
At the same time, the batch voices both arrived and continued to do:
How can caching affect only voices, but never affect verification voices?
We also noticed that a discontinuous change in the number of votes is not synchronous for two counters. The lower counter “catches up” the upper in about a minute. This behavior is not typical for normal voting through the site. This is more like a bot voting without the decision_id parameter with the difference that when voting without a decision_id, the increment of the upper counter is canceled, and in this case we see that the lower counter adjusts to the upper one:
date / time | lower counter | top counter | voices per hour
2014-12-01 00:48:06 87947 87947 1
2014-12-01 00:48:12 87948 87948 1 +1 (vote)
2014-12-01 00:48:16 87948 87948 1
...
2014-12-01 00:51:51 87948 87948 1
2014-12-01 00:51:57 87948 87947 1 -1 (asynchronous voice cancellation)
2014-12-01 00:52:02 87948 87947 1
2014-12-01 00:52:06 87948 87947 1
2014-12-01 00:52:11 87948 87947 1
2014-12-01 00:52:17 87948 87947 1
2014-12-01 00:52:21 87948 87947 1
2014-12-01 00:52:27 87948 87947 1
2014-12-01 00:52:32 87948 87947 1
2014-12-01 00:52:36 87948 87947 1
2014-12-01 00:52:42 87947 87947 1 counter correction
2014-12-01 00:52:46 87947 87947 1
...
2014-12-01 01:14:06 87947 87947 1
2014-12-01 01:14:12 87948 87948 1 +1 (voice)
2014-12-01 01:14:16 87948 87948 1
...
2014-12-01 01:16:46 87948 87948 2
2014-12-01 01:16:52 87949 87949 2 +1 (voice)
2014-12-01 01:16:56 87949 87949 2
...
2014-12-01 01:21:52 87949 87949 2
2014-12-01 01:21:57 87949 87948 2 -1 (asynchronous voice cancellation)
2014-12-01 01:22:01 87949 87948 2
2014-12-01 01:22:07 87949 87948 2
2014-12-01 01:22:11 87949 87948 2
2014-12-01 01:22:17 87949 87948 2
2014-12-01 01:22:22 87949 87948 3
2014-12-01 01:22:26 87949 87948 3
2014-12-01 01:22:32 87949 87948 3
2014-12-01 01:22:36 87949 87948 3
2014-12-01 01:22:42 87948 87948 3 counter correction
2014-12-01 01:22:46 87948 87948 3
...
2014-12-01 01:26:06 87948 87948 3
2014-12-01 01:26:12 87949 87949 3 +1 (voice)
2014-12-01 01:26:16 87949 87949 3
2014-12-01 01:26:22 87949 87949 3
2014-12-01 01:26:26 87949 87949 3 -1 (vote recall)
2014-12-01 01:26:32 87948 87948 3
2014-12-01 01:26:36 87948 87948 3
2014-12-01 01:26:42 87949 87949 3 +1 (voice)
2014-12-01 01:26:46 87948 87948 3 -1 (vote recall)
2014-12-01 01:26:52 87948 87948 3
2014-12-01 01:26:56 87948 87948 3
2014-12-01 01:27:02 87948 87948 3
At some point, it turned out that the domain www.roi.ru two IP look into the world.
www.roi.ru. 299 IN A 109.207.2.37It was assumed that these are two front-end servers, between which replication can be configured, giving a delay. A script was written that synchronously collected meter data from these two IP addresses. The result coincided within two seconds. That is, frontend out of sync could not give the effects described above.
www.roi.ru. 299 IN A 109.207.2.34
Result
At the moment, the reasons for the appearance of regular package additions and subtractions of votes are not clear to us. It looks more like an internal factor, but its nature remains a mystery. In the comments, please express your versions of what is happening (technical, not conspirological).
Recently, a good detailed analysis of voting schedules has appeared. Personally, I do not agree with all the conclusions of the author. For example, many conclusions are made with the assumption that the robot can vote perfectly simultaneously from several accounts. In reality, this is only possible if the robot is on the same server as the POI database.
Related Information
- Post with other examples of voting anomalies
- The voting progress on the schedule, the schedule with the amount of votes for each day
- Per-minute graph showing group reviews of votes
- Another chart with the increase in votes by the minute
- Excellent time-bound graphics
Update
ROI rolled out update:
- Now you can not recall the voice ;
- counters are updated not immediately after the vote, but once a minute.
Now you can not even make sure that your voice is taken into account ;
- the six-minute anomalies were turned off (in fact, this proves that they were not made by an outside robot, but by the ICs).
If disabling a callback is, on the whole, a positive thing, then meter caching is a strong blow to independent monitoring. However, polls have many more strange moments. Perhaps it is time to prepare the continuation of the post.
Update 2
The head of the E-Democracy Foundation Ilya Massuh told about the project news . But it is somehow strange ... He writes that there used to be caching, although experimentally we could not find it. He writes that the withdrawal of the initiative to the top by auto-voting was a discovery for him, although this is not the case (the author of the spin-off initiative himself spammed all the ROIs with this information). This is explained by the fact that “all this activity occurred parallel to the process of improving the algorithms” (I translate: the light from Venus reflected from the upper layers of the atmosphere and caused an explosion of marsh gas). But now the algorithm has really improved : a cache has appeared, so within a minute you can do anything with your voice, no one will even know about it.
I propose to discuss a plan of action . It is important!Source: https://habr.com/ru/post/244753/
All Articles