こうした対策はイタチごっこになりやすい。Chrome 76 の対策には、すぐさま回避する方法が案出された（参照：CNET Japan）。 　複数の方法が編み出されており、その1つは「Quota Management API」というマイナーな仕組みを利用したものだ。この「Quota Management API」は、HTML5 のオフラインのストレージを管理するためのものだ。このAPIを利用して、クライアント側のストレージの容量を知ることができる（参照：Vikas Mishra）。 　筆者も実験してみたが、シークレットモードでは通常モードよりも小さな値が返ってくる。これはシークレットモード判定への対策に、小さな仮想RAMを作ったのが原因だと思われる。判定のためだけに用意しているので、大きな容量にする必要はないと考えたのだろう。その穴を突かれたわけだ。 　もうひとつの方法は、「Filesystem API」の書き込み速度を測定するというものだ。HDDにデータを保存するのと、仮想RAMにデータを保存するのでは、前者の方が時間が長く掛かる。そのため大きなデータを作り、保存速度を比較すれば、シークレットモードか否かを判定できる（参照：Jesse Li）。 　こうした抜け穴は、既に修正の取り組みが開始されている。すぐに穴は塞がれ、新しい方法が考案されるだろう。 　今回は、シークレットモード周りで、プライバシーを保護したいというユーザー側の意思と、個人を特定して収益化をしたいという企業側の思惑のあいだで対立が生じた。 　匿名化と収益化は、対立しやすい概念だ。Chrome を送り出している Google 自体、個人情報の収集によって、広告を最適化して収益を上げている。完全に匿名のWeb世界では、その収益性は格段に落ちるだろう。 　Google がWebブラウザを支配する社会では、シークレットモードは、あくまでも緊急避難的なモードであり、デフォルトのモードになることはない。 　昨今は、2018年5月に施行した「EU一般データ保護規則」（General Data Protection Regulation; GDPR）によって、個人情報の取り扱いが厳しくなっている。将来的には、個人が匿名でアクセスしたいと望むなら、それを弾くのではなく、受け入れる体制がサイト管理者側には求められているのではないか。