「Googleで続ける」をタップし、アカウントを選ぶ。次に見えるはずのものはToRunです。多くの人が代わりに目にしたのは、メールを確認しに行くよう求めるページでした。それは、その三十秒前にGoogleが本人に代わって検証したばかりの同じアドレスでした。
私たちはこれを数えることで見つけました。確認済みアドレスがログインに必要というルールが有効になって以来、Googleで作成されたアカウントの四分の一以上が一度もログインしていませんでした。セッションゼロ、一度もなし。彼らはアカウントを作成し、壁に跳ね返されていたのです。
なぜ起きたのか
私たちが使っているフレームワークは、一つのブランチでしかアドレスを自動確認しません。登録中に人が確認コードを入力する流れです。そのブランチは私たちのところでは無効になっています。ソーシャル登録にはコードを入力する場所がないからです。そのためGoogleやAppleでの完了はすべて未確認のアカウントを作成し、プロバイダーがまさに保証したばかりの受信箱に確認リンクを送り、誰もログインさせないまま確認ページへリダイレクトしていました。
何も失敗していませんでした。エラーは一切記録されていませんでした。そのページは誰かに見せても妥当なもののように見えていました。
まさにこの状況のための保護策が数週間前に追加されていましたが、一度も発動しませんでした。なぜならそれはログインページに存在し、Googleの二つのボタンはまったく別の経路を通るからです。
確認済みで生まれる
GoogleまたはAppleで作成されたアカウントは今、登録されたアドレスが実際にプロバイダーが主張したものである限り、確認済みの状態で始まります。プロバイダーがアドレスを検証していないと明示的に述べる場合、その信頼は与えられず、従来の流れが実行されます。何らかの理由で確認が失敗した場合も、従来の流れが実行され、リンクが送信されます。
フレームワークが送信していたはずの確認メールは、送信ではなく沈黙で応答されるようになりました。そのため、すでに確認済みのものを確認するよう求めるメールを誰も受け取りません。
アドレス自体は今、完了ページで読み取り専用になっており、プロバイダーがそれを検証したことを説明する一文が29言語で用意されています。そしてスマホでは、登録から確認画面への遷移がスタックをリセットするため、戻る操作はユーザー名とアドレスがまだ編集可能な半分入力されたフォームではなく、ログイン画面に着地します。
誰も修復する必要はない
古い壁の向こうに取り残されたアカウントに移行は必要ありません。次に「Googleで続ける」をタップすれば確認されます。これは以前の修正以来ずっと真実で、それが復旧経路のすべてです。
これを捕捉すべきだったチェック――ログイン経路を読み取り、それぞれの動作を確認するもの――は、これが壊れていた四週間の間ずっと緑のままでした。それが観察するすべてのフックが、この流れが決して触れないページに存在していたからです。今ではそれが実際に触れるページに十二の新しいチェックがあります。