追記:
この記事に書かれているChromeの対応はChrome 81でロールバックさせるそうです。コロナで対応出来ない重要組織(病院など)を考慮した結果、とのことです。
Chromeのサードパーティー製Cookie対策、新型コロナによる混乱回避のため一時後退 - ITmedia NEWS
をご覧ください。
以下もとの記事です。
はてなブログの進めているHTTPS化は時流に乗った、正しい選択であることは間違いないと思いますが、以前からブログを開設しており、記事数がそれなりにある著者の皆さんにとっては、面倒な作業だと思います。
セキュリティ的にみて、このHTTPS化とは何なのか、調べてみました。
はてなブログは一般の方や企業が情報発信に使うケースが多そうです。その場合、企業の要求でHTTPS化が「出来ること」は重要ですが、例えば私のブログまでHTTPSで保護する必要性ははっきり言って低くそうです。公開ブログに秘匿性は関係ないし、HTTPSは可用性には貢献しません。意味があるのは完全性(この場合通信経路で改竄されないこと)だけです。一方HTTPS化には暗号処理、証明書設定などコストがかかります。ですから(私のような)無料ユーザのブログまで(無料のまま)やるのははてなとしても厳しいものがあると思います。
一方、上記のような資産のリスク分析とは別に、ブログ表示に使われるブラウザ側に別の要件が発生しているのです。それが、SameSite=None;Secure対策です。
ウェブサイトは様々な目的で、訪問者に対してクッキーを発行しブラウザに保存します。そして次回の訪問の際にブラウザがそのクッキーをサイトに送出することで、セッションにまたがる設定保存や認証を行うことができます。これにより様々なサイトが提供するサービスの連携を実現することができます。同時にクッキーはユーザの行動履歴を見るなどの目的で広告業者によっても使われます。
クッキーは発行したサイトだけが読める、とは限りません。認証に関わるようなクッキーは当然そのサイトだけが読めるように設定されている(SameSite=Strict or Lax)と思いますが、それ以外のほとんどのクッキーは他のサイトでも読み取ることができる(クロスサイトクッキー)と上記の文書には書かれています。なぜならそれがデフォルトの設定(SameSite=None)だからなのです。
Chrome 80以降はこのデフォルト設定が変わり、明示的なSmaeSite設定がない場合、クッキーを発行したサイトだけが読めるようになります(SameSite=Lax)。サイト訪問者にとっては素晴らしいことです。
サイト側にとっては、、、ちょっと迷惑です。今まで様々なドメインを使い分けて複数のサービスを提供し、それらを連携させつつ使い勝手を確保するために、共通のクッキーを利用してきたのですが、それがChrome 80以降、クッキー発行の際にSameSite=Noneと書いておく必要が出てきました。ここまでなら設定を追加するだけですし、HTTPSは関係ないはずだったのですが、、、
Chrome 80から、サイト側がクッキーにSameSite=Noneという設定を書いて送出しても、secure設定(Secure=true)が書いてないとChromeが受け取らなくなりました。そしてSecure=trueと設定されたクッキーはHTTPSでしか送出されないのが決まりです。ここでようやくHTTPSが要件として登場しました。
こうなるとサイト側はSameSite=Noneのクッキーでサービス間連携を実現しつつ、全てHTTPS通信でやるか、HTTP通信とSameSite=LAXのクッキーを使ってサービス間連携を実現するか、どちらか選ぶ必要が生じます。
古くから多くのサービスを運営し、それらを連携させてきているはてなのような企業では、従来出来ていたサービス間連携がSameSite=LAXでは実現できない、ということが多そうです。事ここに至って、SameSite=Noneでクッキーを使うために、HTTPS化が必須になってしまった、つまりサービス設計要件になってしまったのではないか、と想像します orz 。
最初の方で、私を含め一般の方のブログ自体の資産の特性上、保護の必要性が低いと書きました。公開ブログは公開前提なので、HTTPSの暗号通信で秘匿性を守る意味はありません。一方、完全性については、通信経路上で勝手に本文を改竄(例えば本文に広告を挿入される)されることはある程度防げるかもしれません。しかし、それもすでに様々な広告を挿入しているはてなブログ側の問題、とも言えそうです。
ブログ著者として、はてなブログのHTTPS化を有効化する際に必要な作業は3つです。
上記の3つ目のポイントはブログ表示には必須ではありませんが、アドレスバーに「保護されていない通信」などと表示されるのを防ぎ、ちゃんと鍵マークが表示されるために必要です。HTTP通信で得た部分とHTTPSで得た部分が混じったページをMixed content呼び、安全とはみなさないようです。
まだ対応されていないはてなブログ著者の皆さんは、これを機会に早急対応を進めましょう。この流れからすると、遠くない将来、ブラウザでのHTTPのサポート停止なども予想されます。
最後に、はてなブログ運営側からの発信情報へのリンクを載せます。情報は結構あり非常に参考になりました。