すべての非HTTPSページにシークレットモードで警告表示、開発版ChromeにGoogleが実装

Google は、シークレットモードでアクセスするすべての 非 HTTPS(通常のHTTP) ページに対して警告を表示する計画だ。今年の10月にリリースする Chrome 62 からの実装を予定している。この仕様が開発版 Chrome の Canary に一足早く実装された。

- すべての非HTTPSページにシークレットモードで警告表示、開発版ChromeにGoogleが実装 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

Google、Chromeのシークレットモードでアクセスする全ての非HTTPSページに「保護されていない通信」ラベルを。今年10月から

Google は、Chrome ユーザーのプライバシー保護をより一層強化することにした。次のどちらかの条件に当てはまるページに Chrome でアクセスした場合、URL 欄に「保護されていない通信」のラベルが付く。データを入力する HTTP ページ、シークレットモードでアクセスする すべての HTTP ページ

- Google、Chromeのシークレットモードでアクセスする全ての非HTTPSページに「保護されていない通信」ラベルを。今年10月から -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

Chrome 56 と Firefox 51 が非HTTPSでパスワードを収集するページに警告表示

非HTTPSでパスワードを送信するページにGoogle Chrome 56 と Firefox 51では警告が出るようになった。HTTPSへの早急な移行が望まれる。

- Chrome 56 と Firefox 51 が非HTTPSでパスワードを収集するページに警告表示 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

“Content-Security-Policy: upgrade-insecure-requests”でHTTPSページの混在コンテンツを解消する方法

安全なHTTPSで通信するページで安全ではないHTTPで読み込ませるリソースが存在すると、「混在するコンテンツ (Mixed content)」 のエラーが発生する。Content-Security-Policy: upgrade-insecure-requests という仕組みを使うと、混在するコンテンツが存在している場合でもHTTPSで強制的に読み込ませることが可能。つまり、混在するコンテンツエラーを回避することができる。

- “Content-Security-Policy: upgrade-insecure-requests”でHTTPSページの混在コンテンツを解消する方法 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

Google Chrome開発版、クレジットカード情報やパスワードを非HTTPSで送信するページに「保護されていない通信」の警告ラベルを表示

クレジットカードの情報やパスワードを非HTTPS/SSL(通常のHTTP)で送信するページに安全ではないことを示す通知の表示を、2017年1月にリリース予定のChrome 56から実装することをGoogleは告知していた。Chromeの開発版であるCanaryにこの機能が一足早く実装された。

- Google Chrome開発版、クレジットカード情報やパスワードを非HTTPSで送信するページに「保護されていない通信」の警告ラベルを表示 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

GoogleのHTTPSアルゴリズムはURLの最初の5文字を見ている、混在するコンテンツがあっても優遇される

検索結果で、HTTPSページを(多少)優遇するアルゴリズムをGoogleは採用している。このアルゴリズムは、完全に安全な通信ができているかどうかや証明書の有効性を厳密には考慮せず、HTTPSで通信できていさえすれば基本的には優遇を受けられるとのこと。

- GoogleのHTTPSアルゴリズムはURLの最初の5文字を見ている、混在するコンテンツがあっても優遇される -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

Google Chrome、パスワード/クレジットカード情報をHTTPで送るページに安全ではないことを示す「Not secure」ラベルを表示。2017年1月リリースのバージョン56から

[レベル: 初〜上級]

パスワードまたはクレジットカードの情報をHTTP接続で送るページに、安全ではないことを示すラベルをChromeブラウザで表示するようにするとGoogleはアナウンスしました。

2017年1月にリリースを予定しているChromeのバージョン56から実装します。

HTTPページには「Not secure」ラベル

HTTP通信ではセキュリティが確保されません。
そのため、HTTPページでは送信する情報を第三者に盗み見されたり改ざんされたりする可能性があります。
そこで「Not secure」のラベルをアドレス欄に表示するようにしました。

日本語版では「安全ではありません」といったようなラベルになるのではないでしょうか。

下の画像はサンプルです。
上の段は現行のChrome(バージョン 53)です。
特別なラベルは何も付いていません。
しかし下の段のChrome 56からは「Not secure」のラベルがURLの前に付きます。

Not secure ラベル

なお、公式アナウンスには、サイトが対象と書かれていますがページが対象です。
パスワードやクレジットカードの情報をHTTPで送るページがあれば、そのページだけにラベルが付きます。
サイト全体ではありません。

パスワードとクレジットカードの送信フィールドがあるページのみ

Not secureラベルの対象になるのは、パスワードまたはクレジットカードの情報をHTTPで送信するページです。
メールアドレスや住所、電話番号などそのほかの個人情報を送信するページは、(最初の時点では)対象になりません。

もう少し細かく言うと、パスワードやクレジットカードのフォームフィールドがあるHTTPページになるかと思います。

対象範囲を拡大する可能性も

すでに説明したように、2017年1月リリースのバージョン56では、パスワード/クレジットカードをHTTPで送信するページだけがラベルの対象です。

しかし対象範囲をさらに拡大していきたいとのことです。

たとえば、シークレットモードでChromeを利用する場合です。
シークレットモードは、ユーザーがプライバシーを保護したいときに使われます。
そこで、シークレットモード利用時はすべてのHTTPページにNot secureラベルを表示するかもしれません。

最終的には、モードに関係なく、すべてのHTTPページにNot secureラベルを表示することを目指しています。
しかも赤色の警告マークも付けるかもしれません。

警告マークつきのNot secureラベル

今から準備を

「安全ではありません」なんて表示されたらアクセスしたくなるユーザーがおおぜい出てくることでしょう。

まさかパスワードやクレジットカードの情報を送信する際に、HTTPSを使っていないのは今どきありえないと思います。
それでも、もし万が一そういったページでHTTPのままであれば大至急HTTPSに変えなければなりません。
もっとも、パスワードやクレジットカード情報をHTTPで送らせるなんていうのはChromeのNot secureラベル以前の問題ですが。:(

パスワードやクレジットカードの情報を送信するページを持っていないとしても、HTTPS化は避けて通れないでしょう。
時代の流れなのであらがうことは得策ではありません。
さっさとHTTPSに移行して本当に僕は良かったと思っています。

なお自分のサイトがどんな影響を受けそうか(あるいは受けないか)は、開発版のChrome Canaryで確かめることができます。
安定版がリリースされるだいたい6週間前に新機能が実装されるとのことです。

- Google Chrome、パスワード/クレジットカード情報をHTTPで送るページに安全ではないことを示す「Not secure」ラベルを表示。2017年1月リリースのバージョン56から -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

Google、www.google.comドメインにHSTSを適用。常にHTTPSで接続するように

[レベル: 上級]

Googleが検索を完全にHTTPS化して以来まもなく5年がたちます。
さらにセキュリティを高めるために、www.google.comドメインで HTTP Strict Transport Security (HSTS) の実装を始めたことをGoogleはアナウンスしました。

HSTSを適用したことにより、米Google検索を含む www.google.com ドメインを利用するときの2回目以降は、たとえ http で始まるURLでアクセスしようとしたとしても、ブラウザ側で https に置き換えてアクセスするようになります。

※HSTSに詳しくなければ、Web担当者Forum連載コラムでの解説をご覧ください。このブログのHTTPS移行の際にもHSTS(とPreload HSTS)を実装しています。

www.google.com のHSTSを検証

www.google.com が本当にHSTSになっているかどうかを確かめてみました。

HTTPヘッダー

HTTPヘッダーでは、Strict Transport Security がきちんと返されています。

Strict Transport Securityヘッダー

ちなみに、max-age が「86400」に設定されています。
単位は秒で、86,400秒は1日です。

非常に短い期間ですが、www.google.com は極めて巨大なサイトなので、移行にともなって発生するかもしれない問題を回避するためにあえてこのように短く設定しているとのことです。
今後数か月かけて、最低でも1年間の有効期間になるまで徐々に増やしていく予定です。

GoogleニュースのHTTPS移行でも、max-age を徐々に増やしていくことをGoogleはアドバイスしていましたね。

僕は最初から1年(31536000秒)でした。w

Google Chrome

Chromeのアドレスバーに「chrome://net-internals/#hsts」を打ち込むことで、ブラウザ(Chrome)が認識しているHSTSのステータスを調査することができます。

www.google.comで検索します。
「dynamic_upgrade_mode」の「STRICT」が、HSTSが適用されていることを示しています。

dynamic_upgrade_mode: STRICT

www.google.co.jpには(まだ?)HSTSは実装されていません。
「dynamic_upgrade_mode」は「UNKNOWN」になっています。

dynamic_upgrade_mode: UNKNOWN

307リダイレクト

ブラウザがHSTSを認識している状態で、HTTPの http://www.google.com にアクセスしてみました。

307リダイレクトが返っています。

307 Internal Redirect

307はブラウザ内部でのリダイレクトです。
HSTSが正常に動作している証拠ですね。

GmailやYouTubeはすでにHSTSを実装しています。
Google検索のHSTS適用はむしろ遅めだったのかもしれません。
今のところは、www.google.com だけですが、いずれは www.google.co.jp はもちろんのこと世界中のGoogleに広めていくのでしょう。

常時HTTPSのサイトをあなたも運営しているなら、セキュリティをさらに高めるためにもHSTS(とPreload HSTS)の実装をお忘れなく。

- Google、www.google.comドメインにHSTSを適用。常にHTTPSで接続するように -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

Googleニュース登録サイトのHTTPからHTTPSへの移行に際してよくある質問にGoogleが回答

HTTPからHTTPSへの移行に際して、Googleニュースに登録しているパブリッシャーからよく尋ねられる質問とその回答を、Google+のGoogleウェブマスター公式アカウントが共有しました。

We collected a few questions from news publishers related to HTTP to HTTPS site moves, but some of the answers are relevant to all webmasters who are considering going secure.

長山さんがそのうち日本語に訳してくれるように思いますが、それまでのつなぎとして代わりに僕が翻訳したものをこのブログに掲載します。

基本的には、Googleニュースに登録しているサイト向けですが、一般サイトのHTTPS移行のときにも役立つ情報も含まれています。

ではお読みください。

Googleニュース登録サイトのHTTPS移行でよくある質問

Q. HTTPSに一度に移行すべきですか? それとも少しずつ移行すべきですか?

A. トラフィックとインデックスに影響がないかどうかをテストするために、サイトの一部分だけを初めは移行することを推奨します。その後は、サイトの残りを一度に移行してもいいし、部分部分に分けて移行しても構いません。

サイトの最初にテストするセクションを決める際には、変更する頻度が少なく、頻繁だったり予測できなかったりする出来事によって大きな影響を受けないセクションを選ぶようにします。

1つのセクションだけを移行するのは移行を試すのにとてもいい方法ですが、検索に関して言えば、必ずしもサイト全体の移行の見本になるとは限らないことを覚えておいてください。多くのページを移行すれば移行するほど、解決が必要になってくる別の問題に直面しやすくなります。問題を最小限に抑えるために、綿密に計画します。

Q. どのくらいの期間テストを実行すべきですか?

A. クロールとインデックスが変更を認識できるようにするため、それに加えてトラフィックを監視するために数週間を予定してください。

Q. 1セクションだけから始めたとしても、サイト全体をHTTPSで利用できるように計画しています。HTTPSのコンテンツが先にインデックスされないように、リダイレクトやrel=”canonical”を使うべきですか?

A. 技術的な仕組みから、リダイレクトを設置したらそういったページ(HTTPでインデックスさせたままのHTTPSページ)をテストできないでしょう。したがって、rel=”canonical”を推奨します。

Q. HTTPのサイトマップをrobots.txtで参照しています。HTTPSの新しいサイトマップを含むように更新すべきでしょうか?

A. HTTPのサイトマップとHTTPSのサイトマップをそれぞれ指すように、HTTP用とHTTP用にrobots.txtファイルを別々に分けることを推奨します。また、1つのURLは片方のサイトマップだけに記述するようにすることも推奨します。

Q. HTTPS化のテスト中は、HTTPSのセクションをどちらのサイトマップに記述すべきでしょうか?

A. 移行するセクションだけのサイトマップを別個に作ることができます。こうすれば、テスト対象のセクションのインデックスをより正確に追跡できます。ただし、テスト対象のURLがほかのサイトマップに重複しないようにくれぐれも注意してください。

Q. HTTPSバージョン用のrobots.txtに、特別に何か追加するものはありますか?

A. いいえ、ありません。

Q. 私たちのHTTPSサイトは、まだ移行していないページをHTTPにリダイレクトして戻しています。サイトマップには何を記述したらいいでしょうか? HTTPとHTTPSの両方のURLをサイトマップに記述するのでしょうか? テストしているセクションで、HTTPのURLがHTTPSのURLにリダイレクトしている場合はどうなるでしょうか?

A. ユーザーが訪問したときにリダイレクトするかどうかにかかわらず、HTTPのURLはすべてHTTP用のサイトマップに、HTTPSのURLはすべてHTTPS用のサイトマップに記述します。リダイレクトとは関係なしにサイトマップにページを記述すれば、新しいURLを検索エンジンがより早く発見する手助けになります。

Q. includeSubDomains をHSTSヘッダーに設定した場合、どのドメインに影響しますか?

A. サイト全体をHTTPSに移行したあとは、セキュリティをさらに高めるためにHSTSプリロードに対応させることができます。HSTSを有効にするためには、includeSubDomains ディレクティブをHSTSヘッダーに設定しなければなりません。

includeSubDomains が設定されたHSTSヘッダーを www.example.com のサイトが返したとしたら、次のようなドメイン名のサイトに適用されます。

  • www.example.com
  • foo.www.example.com

しかし、次のようなドメイン名のサイトには適用されません。

  • notexample.com
  • foo.example.com

ただし、HTTPに戻す際の手順をHSTSは複雑にします。次のステップを推奨します。

  1. まず、HSTSなしでHTTPSを展開する。
  2. 短い期間を指定した max-age でHSTSヘッダーの送信から始める。ユーザーとほかのクライアントの両方からのトラフィック、また広告などの付属要素のパフォーマンスを監視する。
  3. HSTSの max-age の期間を徐々に増やしていく。

HSTSがユーザーと検索エンジンに悪い影響を与えなかったら、望むのであれば、ChromeのHSTSプリロードリストにサイトを追加するように依頼できます。

[鈴木補足: HSTSとプリロードHSTSがわからない人は、Web担当者Forumのコラムでの解説記事をお読みください。]

Q. サイト全体に対して単体のGoogleニュースサイトマップを使っています。部分的に少しずつ移行するとしたらどうしたらいいですか?

A. HTTPSの新しいセクションに対してニュースサイトマップを使いたいのであれば、プロトコルが変わったことを知らせるためにニュースチームにコンタクトを取らなければなりません。その後、Search ConsoleのHTTPSのプロパティで、HTTPSに移行したセクションごとに新しいGoogleニュースサイトマップを送信できます。

Q. HTTPSの移行に伴って、Google ニュース パブリッシャー センターでやることが推奨されるようなことは何かありますか?

A. パブリッシャーセンターはHTTPからHTTPSへの移行を透過的に処理します。ニュースサイトマップを利用しないのであれば、一般的には、Googleニュースの観点からは何もする必要はありません。その場合は、ニュースチームにコンタクトして変更について知らせてください。変更したセクションについても知らせることができます。たとえば、HTTPSへ移行している場合は、http://example.com/section を https://example.com/section へ移行していることを指定できます。

以上です。

常時HTTPSへの移行を計画している人は、僕のブログのHTTPS移行時のステップ・バイ・ステップも参考にしてください。

- Googleニュース登録サイトのHTTPからHTTPSへの移行に際してよくある質問にGoogleが回答 -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki

HTTPS移行でPageRank喪失は起こらない、たとえ302リダイレクトであっても ―― HTTPS移行FAQフォローアップ

Web担当者Forumの連載コラムでピックアップした、Googleのジョン・ミューラー氏によるHTTPS移行によくあるQ&Aのフォローアップ。HTTPS移転でPageRankは失われない、301でも302でもどちらでも使える、移行処理を速めるためにHTTPのサイトマップを送信するなど。

- HTTPS移行でPageRank喪失は起こらない、たとえ302リダイレクトであっても ―― HTTPS移行FAQフォローアップ -

Posted on: 海外SEO情報ブログ - SuzukiKenichi.COM by Kenichi Suzuki