皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

さて、今日は冒頭に書いた昨日の記事『Chrome 80でECサイトに影響』の続きです。

Chrome 80の登場とECサイト対策

昨日の記事の最後では、

ECサイトなどにおいてこの『SameSite属性』が指定されていない場合、・・・中略・・・ECサイトなどによっては『ログイン情報が保持できない』、『カートの商品が保持できない』、『複数商品が購入できない』などといったことが起こる可能性があります。

これ以外にも問題が発生し得る条件などがあり・・・

ということを書きましたが、その条件というのは『クロスサイト（異なるドメイン（複数サイト）間）』での挙動に関してということになります。

具体的には『ドメインA』でログインし、その後に『ドメインB』に遷移する挙動がある場合などです。

このケースにおいては『SameSite属性』によって対応が異なります。

＜SamteSite=None＞

・SSL化（HTTPS化）されていること

・Cookie（クッキー）にSecure属性が付与されていること

この2点が満たされていれば今まで通り動作します。

＜SameSite=Lax＞

※　ECサイト側で指定がない場合はGoogle Chromeの既定値となる『SameSite=Lax』となります。

・『SameSite=None』に変更して対応

・『SameSite=Lax』を使用する場合、『サイト全体の常時SSL化（HTTPS化）』＋カートボタンなどの『method属性』を『post』から『get』に変更して対応

＜SameSite=Strict＞

セキュリティレベルが3つの中で一番高いもので、主に金融機関などで用いられると考えられるため割愛します。

大まかには以上のよう感じです。

ご参考までに。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

さて、冒頭に書いた通り『Google Chrome 80』がリリースされたわけですが、『Google Chrome』はこのバージョンから『プライバシー保護』などを目的に一部仕様が変更されます。

（実際には約2週間後あたりのマイナーアップデートから段階的に行われるようです。）

今回の仕様変更は『ECサイト』などに影響しますので、今日はそれをご紹介します。

Chrome 80がECサイトに与える影響

今回の『Google Chrome 80』では『Gookie（クッキー）』というブラウザに一時保存されたデータの動作が変更になります。

つまり、『ログイン』や『カート』に入っている商品などの情報を『Gookie（クッキー）』を使って保持している『ECサイト』などにおいては影響が出るわけです。

では、『Google Chrome』における『Cookie（クッキー）』の扱いはどのような変更がされるのか？

『Google Chrome』には、CSRF（cross-site request forgeries：クロスサイトリクエストフォージェリ）という攻撃からユーザーを保護するため『SameSite』という『Cookie（クッキー）』に付与される属性があります。

この属性には3つのものがあり、

None　⇒　Lax　⇒　Strict　の順にセキュリティレベルが厳格になっていきます。

そして、ECサイトなどにおいてこの『SameSite属性』が指定されていない場合、『Google Chrome』からアクセスした際の『Cookie（クッキー）』の扱いが『Google Chrome 79以前』の既定値『None』から『Google Chrome 80以降』では『Lax』に変更されるため、ECサイトなどによっては『ログイン情報が保持できない』、『カートの商品が保持できない』、『複数商品が購入できない』などといったことが起こる可能性があります。

これ以外にも問題が発生し得る条件などがありますが、それに関してはまた後日お伝えしたいと思います。

今日のところはこの辺で。。。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

日本時間の今日、WordPressの更新版であるWordPress4.9.7が公開されました。

今日はそのニュースをお伝えします。

WordPress3.7以降のすべてに向けたリリース

WordPressのブログニュースを見ると、今回のリリースもWordPress3.7以降のすべてのバージョンのセキュリティ及びメンテナンスリリースで、直ぐにWordPressをアップデートをすることが強く推奨されています。

また、WordPress4.9.6以前では、特定の権限を持つユーザーがuploadsディレクトリ外のファイルを削除しようとするメディアの問題の影響を受ける可能性があるともされています。

これ以外にも、

・用語クエリのキャッシュ処理の改善

・ログアウト時の投稿パスワードのCookieのクリア・

・ウィジェット管理画面のサイドバー説明に基本的なHTMLタグを許可する

など、17のバグ（不具合）修正も行われています。

いつもながら、マイナーアップデートが自動更新になっている場合はそのまま自動的に更新がなされます。

ただし、以前にもご紹介した通り、『WordPress4.9.3』において自動バックグラウンド更新をサポートするサイトが自動的に更新されないというバグ（不具合）があったため、手動で4.9.4以降にアップデートされていない場合は自動更新されることはないと思われますので、念のため管理画面で確認をしておくことをお勧めします。

マイナーアップデートも自動更新を『オフ』にしている場合は早めにアップデートされることがお勧めです。

そして、両社のCEO（最高経営責任者）であるイーロン・マスクは個人のFacebookアカウントも削除し、SNS上では『#deletefacebook（フェイスブックを削除せよ）』が拡散されている。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

海外では『#deletefacebook（フェイスブックを削除せよ）』という動きが広まっているようですが、とは言えFacebook（フェイスブック）というコミュニケーションツールを手放してしまうことはなかなか難しいとも言えます。

そんな中、Mozillaが新たなものをリリースしてきました。

Facebookによるデータ追跡を制限する

Mozillaは、『予想外の副作用からユーザーを守る』として、ブラウザのFirefoxのアドオンに『Facebook Container』というものを加えてきました。

このアドオンを使うことにより、以下のことに対処できるとされています。

Facebook Container works by isolating your Facebook identity into a separate container that makes it harder for Facebook to track your visits to other websites with third-party cookies.
（Facebookコンテナは、FacebookのIDを別のコンテナに隔離することによって機能し、FacebookがサードパーティのCookieを使用して他のWebサイトへの訪問を追跡することを困難にします。）

ただし、このアドオンですべてが解決できるわけではありません。

It is important to know that this extension doesn’t prevent Facebook from mishandling the data that it already has, or permitted others to obtain, about you. Facebook still will have access to everything that you do while you are on facebook.com, including your Facebook comments, photo uploads, likes, any data you share with Facebook connected apps, etc.
（この拡張機能によって、Facebookが既に持っているデータを誤って取り扱うことや、他の人にあなたの入手を許可することが妨げられることはありません。あなたのFacebookのコメント、写真のアップロード、好きなもの、あなたがFacebookに接続しているアプリケーションと共有しているデータなど、facebook.comにいる間にあなたがやっているすべてのことにFacebookは依然としてアクセスします。）

This extension focuses on limiting Facebook tracking, but other ad networks may try to correlate your Facebook activities with your regular browsing. In addition to this extension, you can change your Facebook settings, use Private Browsing, enable Tracking Protection, block third-party cookies, and/or use Firefox Multi-Account Containers extension to further limit tracking.
（この拡張機能はFacebookのトラッキングを制限することに重点を置いていますが、他の広告ネットワークはあなたのFacebook活動をあなたの通常のブラウジングと相関させようとするかもしれません。この拡張機能に加えて、Facebookの設定を変更したり、プライベートブラウジングを使用したり、トラッキングの保護を有効にしたり、サードパーティのCookieをブロックしたり、Firefoxのマルチアカウントコンテナの拡張機能を使用してトラッキングをさらに制限することができます。）

NOTE: If you are a Multi-Account Containers user who has already assigned Facebook to a Container, this extension will not work. In an effort to preserve your existing Container set up and logins, this add-on will not include the additional protection to keep other sites out of your Facebook Container. If you would like this additional protection, first unassign facebook.com in the Multi-Account Container extension, and then install this extension.
（注：Facebookにコンテナを割り当て済みのマルチアカウントコンテナユーザーの場合、この拡張機能は動作しません。既存のコンテナの設定とログインを維持するため、このアドオンにはFacebook Containerから他のサイトを保護するための追加の保護は含まれません。この追加の保護をご希望の場合は、まずマルチアカウントコンテナ拡張でfacebook.comの割り当てを解除し、この拡張機能をインストールしてください。）

このようなアドオンも有効的ではあるものの、利便性を優先したプラットフォームの連携を行わないようにすることも必要かと思います。

例えば、Facebook以外のサイトなどのログインに『Facebookアカウントでログイン』を使わないということです。

ご参考までに。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

以前の記事において、パフォーマンス向上やサイトのパフォーマンステストのスコア改善などを目的とした、あるテストとその結果を書きました。

それは、一部弊害をもたらすことがあります。

シンボリックリンクにおける問題

まず前提として、不要なCookieトラフィックを避けるために、画像ファイルなどの静的コンテンツを別ドメインから提供して解決するということを前提に行ったものです。

例えば、www.example.com/content/abc.jpg という画像があったとします。

これを、static.example.com/content/abc.jpg として提供する。

これは、static.example.com/content/ -> www.example.com/content/ と張られたシンボリックリンクを使って解決しようとしたものですが、これには少々弱点があります。

画像などの静的コンテンツの追加や変更があった場合、それが確実には反映されないという現象が出てしまうことがあるのです。

そのため、キャッシュされているものを一度パージ（クリア）する必要性が出てきてしまいます。

この弱点を克服するとなると、シンボリックリンクを張るというのではなく、リンクの張られていないURLとしてアクセスするしかありません。

しかし、その場合はウェブサイトの管理的に少々煩雑になってしまうなどの問題が出てきてしまうため、それでも問題のない方以外はお勧めいたしません。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

今日は、先日書かせていただいた記事の結果報告です。

Use cookie-free domainsのおさらい

まず少しおさらいですが、GTmtrixにて『Use cookie-free domains』という項目のスコアが悪いのは、不要なcookieトラフィックを避けるために別のドメインの静的コンテンツを提供すべきであることを意味していて、

例えば、例えば、www.example.com/content/abc.jpg という画像があったとするならば、

これは、static.example.com/content/abc.jpg として提供すべきだという意味であることを先日書きました。

そして、画像以外にもJavaScriptやcssも同様のことが言えます。

cookie対策として行ったこと

前提：メインで稼働しているのは『www.example.com/blog/』とします。

１．別途、『static.example.com』というドメインを設定

２．static.example.com/blog/wp-content -> www.example.com/blog/wp-content というシンボリックリンクを貼る

３．config.phpに次のものを追加

　　define(‘WP_CONTENT_URL’, ‘http://static.example.com/blog/wp-content’);

　　define(‘COOKIE_DOMAIN’, ‘www.example.com’);

　　define(‘WP_PLUGIN_URL’, ‘http://www.example.com/blog/wp-content/plugins’);

注：WP_CONTENT_URLはプラグインの部分も影響するため、WP_PLUGIN_URLを書く必要がある

４．画像、css、JavaScriptが書かれているurlを『WP_CONTENT_URL』を読み込むように修正

以上のことを行いました。

測定結果は？

結果として、パフォーマンスが落ちるところまではいかないまでも、パフォーマンスが向上することはありませんでした。

また、GTmtrixの『Use cookie-free domains』に変化はなく、スコアは悪いままで、調整次第ではGoogleのPageSpeed Insightsにおいても悪い結果となります。

ここで言えるのは、cssは通常通りに読み込ませた方が良いです。

レンダリングのスコアに影響します。

画像やJavaScriptに関してはブラウザーキャッシュが効いていれば大丈夫ですが、だからと言って特別パフォーマンスが向上するわけではありません。

結果として、対策を行ったとしてもGTmtrixのスコアが伸びるわけでもなく、実際のパフォーマンスに関しても気休め程度の話しにしかなりませんでした。

これはおそらく、シンボリックリンクを使わずに実ファイルを別ドメインに持たせたとしても同じ結果になると思われます。

皆さん、こんにちは。

業務改善を行うIT・業務コンサルタント、高橋です。

今日は遅くなってしまったので少しだけ。

ウェブサイトのパフォーマンスを計測したことがある方にはおわかりいただけるかと思いますが、GTmtrixにて『Use cookie-free domains』という項目のスコアが悪いことが多いかと思います。

これは、不要なCookieトラフィックを避けるために別のドメインの静的コンテンツを提供すべきであることを意味しています。

例えば、www.example.com/content/abc.jpg という画像があったとします。

これを、static.example.com/content/abc.jpg として提供すべきだということです。

理由として、Cookie情報が付加されてしまうものに関してはその分若干ではありますがパフォーマンスの低下要因となるため、Cookie情報が付加されないところから提供することによって少しでもパフォーマンスを向上させるということです。

これに関しては私も現在テストを行っていますので、テストが終わり次第、また記事を書きたいと思います。