11月24日、モスクワ時間の13:35に始まりました。 イニシアチブ9376の採択に対する投票カウンターは2減少しました。その後、さらに1と2が減少しました。夕方には、カウンター値の減少がより頻繁に発生し始めました。 誰かがこれに気づき、イニシアチブの作者に通知しました。 その瞬間から、投票プロセスの注意深い監視が始まりました。
過去1週間に私たち（観測者）が気付いた奇妙な投票のいくつかについて説明します。 また、それらのいくつかの理由について推測を試みます。 結論はほとんどありません。 投票プロセスに関する必要なデータを常に取得できるとは限りません。
チャートによると、特定のポイントでカウンターの変化がより急激に発生することがすぐに明らかになりました。 さらに、これらの瞬間は数時間の精度で毎時間同じです。 たとえば、ログでは、3、9、15、21、27、33、39、45、51、57分に票の増加のピークが観察されました。数日後、分が1つシフトしました（4、10、16 ...になりました）。しかし、数時間にわたって、彼らはまだ与えられた分と秒で終わった。
したがって、投票する確率は特定の分に依存します。 一部のイニシアチブでは、この依存関係が顕著です：
一部の場合-より弱い：
ほとんど見えない場所：
しかし、最も興味深いのは、「 職員の違法な濃縮に対する刑事責任について 」というイニシアチブで起こっています。 投票数を減らすためだけに依存関係を示しています。
私が知りたかった主なことは、カウンターの6分のピークがROIの外部のスクリプトの結果なのか、これがサイトの内部メカニズム（キャッシュ、エラー、悪意のある意図）なのか、ということでした。
ボットで投票する機能は非常に現実的です。 ROIを入力するには、State ServiceのWebサイトでアカウントが使用されます。 公共サービスへのアクセスは、VKontakteアカウントと同じ方法で盗まれます。 それはさらに簡単です。国務省は、不正アクセスから保護するための特別な措置を講じていないからです。 たとえば、新しい場所からサイトに入るときにアカウントをブロックしません。
サイトでの投票は、アドレスwww.roi.ru/ajax/votingにポストリクエストを送信することで行われます。 投票ユーザーは、Cookie（SESSIONID）によって決定されます。 イニシアチブと投票のタイプは、POST要求のパラメーターによって設定されます。 明らかに、サーバーへのリクエストの数は投票数と等しくなければなりません。 データ収集間隔が短くなると、個々のユーザー/ボットの声が見えるようになると仮定しました。 投票が通常のピークから外れている場合、 データを2秒ごとに記録して 、投票の過半数を分割するだけで十分です。
複数の反対票のパケットを時間で分割することはできません。 投票のグループは常に同時に加算/減算されます（サーバーと要求処理の応答時間に関連する300ミリ秒のオーダーの変更のエラー内）。 観察できる最大グループは、7票（カウンターの減少）で構成されていました。 投票（/ ajax / voting /）のPOSTリクエストの典型的な実行時間は300..350ミリ秒です。 これらのかなり重いリクエストのうち7つがリモートサーバーからすぐに実行され、監視の履歴全体で1つの障害が発生することはありません。
これはどのようにできますか？
-リクエストは近隣のコンピューターから実行され、複数のスレッドで意図的に同期して実行できます（投票の自然な流れを見せたい場合は意味がありません）。
-または、 投票グループの表示は、ROI Webサイトの内部メカニズムと関連しています 。
ROIの代表者は、パッケージの外観につながる何らかのコードがあることを否定していませんが、明確な説明はしていません。 投票の増加のグラフにピークを持つ画像を提供できる内部メカニズムは何ですか？
-カウンターキャッシング
-マスター/スレーブ方式を使用してデータベースを複製するときの複製の遅れ
-何か他のもの
これらの要因の影響を確認するために、スクリプトを使用して投票と音声リコールを実行し、メーターの測定値の変化を追跡し始めました。 その後、すぐに問題が発生しました。 イニシアチブページには3つのカウンターがあります。総投票数の上位カウンター、総投票数の下位カウンター、および右側の列の時間カウンター（まだ興味はありません）。
サイトを介して投票すると、総投票数のカウンターが即座に（ページの再読み込み時間まで）同期的に変化することがわかりました。 スクリプトで投票すると、上位カウンターのみが変更されました。 数分後、カウンターの読み取り値は以前の値に戻りました。 さらに、カウンターロールバックの分と秒は、ホッピングカウンターの変更の分と秒と一致しました。 そのため、特定のスケジュールに従ってメーターを修正するメカニズムがサイトにあります。 おそらく、同じメカニズムがカウンターの痙攣性の変化に関与しています。 変更の時間は彼の仕事のスケジュールと一致します。
投票APIが正しく機能するためには、イニシアチブID（petition_id）だけでなく、各イニシアチブに固有の特定のdecision_idも渡す必要があることが判明しました。 両方のパラメーターを渡すと、ボットの音声は両方のカウンターですぐに考慮され、数分後に消えません。 decision_idの目的は不明です。
これで、カウンターの読み取り値を変更する内部メカニズムの性質を理解することができます。 データベースレプリケーション中にキャッシュまたは遅延の影響が発生する可能性があることを想定したことを思い出してください。 私たちは、30秒ごとに「賛成」投票と投票廃止を実行し始めました。 投票とキャンセルの間隔は、さまざまな実験で5〜20秒でした。 各投票/リコールの後、メーターの測定値のチェックが開始されました。 それらは常に同期的に変化しました。 何百もの測定が、異なる時間に、異なるイニシアティブで行われました。 カウンターが音声に反応しない場合はありません。 スクリプト出力の例：
リフレッシュ
200 72019 72019 2014-12-01 13:26:12
投票
200 success_affirmative 2014-12-01 13:26:16
リフレッシュ
200 72020 72020 2014-12-01 13:26:21
キャンセル
200 success_reject 2014-12-01 13:27:05
リフレッシュ
200 72019 72019 2014-12-01 13:27:10
同時に、パケット音声が到着し、引き続き到着しました。
キャッシュは1つの投票にどのように影響しますが、テストには影響しませんか？
また、2つのカウンターで投票数の急激な変化が同期して発生しないことにも気付きました。 約1分後に、下部のカウンターが上部を「キャッチアップ」します。 この動作は、サイトを介した定期的な投票では一般的ではありません。 これは、decision_idパラメーターなしのボットによる投票に似ていますが、decision_idなしで投票すると、上部カウンターの増分がキャンセルされ、この場合、下部カウンターが上部に調整されることがわかります。
日付/時間| ボトムカウンター| トップカウンター| 1時間あたりの声
2014-12-01 00:48:06 87947 87947 1
2014-12-01 00:48:12 87948 87948 1 +1（音声）
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（非同期音声キャンセル）
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カウンター修正
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（音声）
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（音声）
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（非同期音声キャンセル）
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カウンター修正
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（音声）
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（音声リコール）
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（音声）
2014-12-01 01:26:46 87948 87948 3 -1（音声リコール）
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
ある時点で、ドメインwww.roi.ruには世界を見ている 2つのIP があることが判明しました。
www.roi.ru。 299 IN A 109.207.2.37これらは、遅延を与えるようにレプリケーションを構成できる2つのフロントエンドサーバーであることが提案されています。 これら2つのIPアドレスから同期的にカウンターデータを収集するスクリプトが作成されました。 結果は2秒以内に一致しました。 つまり、フロントエンドの同期解除では、上記の効果が得られませんでした。
www.roi.ru。 299 IN A 109.207.2.34
結果
現時点では、定期的なバッチの追加と投票の減算の出現の理由は明確ではありません。 内的要因のように見えますが、その性質は謎のままです。 コメントでは、何が起こっているのか（陰謀ではなく技術的な）あなたのバージョンを表現するようお願いします。
最近では、投票スケジュールの詳細な分析が行われています。 個人的には、著者のすべての結論に同意しません。 たとえば、ロボットは複数のアカウントから同時に完全に投票できるという仮定で多くの結論が下されます。 実際には、これはロボットがROIデータベースと同じサーバー上にある場合にのみ可能です。
関連情報
- 投票の異常の他の例とともに投稿する
- グラフ上の投票の進捗状況 、各日の投票の合計を含むグラフ
- グループの票のフィードバックを示す分ごとのグラフ
- 分ごとに投票数が増加した別のグラフ
- 高精細の美しいタイムライン
更新する
ROIは更新を展開しました：
- 今、あなたは声を思い出すことができません 。
-カウンターは、投票後すぐに更新されるのではなく、1分に1回更新されます。
今では、自分の声が考慮されているかどうかを確認することさえできません 。
-6分間の異常はオフになりました（実際、これは外部ロボットではなくROIによって作成されたことが証明されています）。
フィードバックを無効にすることが一般的に良いことである場合、カウンタのキャッシュは独立した監視にとって大きな打撃です。 しかし、世論調査にはまだ多くの奇妙なポイントがあります。 おそらく、投稿の続きを準備する時が来たのでしょう。
更新2
E-民主主義財団のイリヤ・マスクフの長がプロジェクトのニュースについて話しました 。 しかし、どういうわけか奇妙な...彼は、以前はキャッシュがあったと書いていますが、実験的にはまだ見つけることができませんでした。 彼は、自動投票で主導権を握ることは彼にとって発見であったと書いていますが、そうではありません（ラッピングイニシアチブの著者自身がこの情報ですべてのROIをスパムしました）。 「この活動はすべてアルゴリズムの改善プロセスと並行していた」と言うことで何が起こっているのかを説明しています（私は翻訳します。 しかし、今ではアルゴリズムが本当に改善されました 。キャッシュが現れたので、あなたは1分以内にあなたの声で何でもできます。
私はアクションプランについて話し合うことを提案します。 これは重要です！