しかし、今後はその状況に変化が起きるかもしれません。

皆さん、こんにちは。

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

さて、Windows PC向けのブラウザソフトにおいて苦戦を強いられている『Microsoft Edge』ですが、今年に入ってある変化を見せました。

それは、レンダリングエンジンを『Chromium（クロミウム）』に刷新したことです。

新しいEdgeがChromeを抜く可能性

『Microsoft Edge』の刷新は『Google Chrome』を抜く可能性が出てきたような気がします。

前述の通り、レンダリングエンジンを『Google Chrome』と同じ『Chromium（クロミウム）』に変更したからです。

新しいChromiumベースの『Microsoft Edge』を使ってみましたが、これなら使っても良いと感じるものになっています。

パフォーマンス面は『Google Chrome』と同レベルになったと言って良いでしょうし、『Google Chrome』の拡張機能も『Microsoft Edge』で使用することができます。

何より大きいのは、行政や金融機関系のWebシステムはMicrosoftに合わせようとする傾向が非常に強いですし、その理由としてはやはりMicrosoftに対する信頼性ということになるのではないでしょうか。

現に、数ヶ月前の段階で『Mozilla Firefox』を抜いて2位まで上昇していますから、『〇〇用』などとブラウザを使い分けるくらいであれば『Microsoft Edge』一つに絞って運用したいと考えるのはごく普通のことです。

特にビジネスシーンにおいてはその方向性が高まるとも言えます。

『Microsoft Edge』はWindows、Mac、iOS、Android、いずれにも対応する『クロスプラットフォーム』なブラウザです。

しかし、これは『USB接続プリンター』だけではなさそうです。

皆さん、こんにちは。

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

つい先日、『Windows 10』の『2020年6月のセキュリティ更新』が配信されたばかりですが、それによってプリンターへの出力に対する不具合が出ているようです。

Windows10から印刷ができない

冒頭で書いた通り、プリンターへの印刷ができないのは『USB接続のプリンター』というインターネットニュースがありましたが、私が試したところによると『Wi-Fi接続されたプリンター』も類似の現象が発生しているように思えます。

ただし、どちらも『ある特定の操作』をした場合に限って発生する不具合のようで、全く印刷ができないというものではないようです。

私が確認した事例は、

１．Windows 10を起動

２．Google ChromeにてGoogle Mapsの地図表示

３．地図をPDFへ出力

４．PDFからWi-Fi接続されたプリンターへ印刷指示

５．プリンターから印刷されず

というものでした。

この問題、『USB接続のプリンター』に関してはMicrosoft（マイクロソフト）のサポートノートにて『Windowsを立ち上げる前に、電源が入ったUSBプリンターを接続することで、この問題を回避できる』と説明しているようですが、『Wi-Fi接続のプリンター』に関しては回避されませんでした。

一方プリンターメーカーの記事では、『2020年6月のセキュリティ更新』をアンインストールするか、『ロールバック』させるかにて不具合を解消させることが紹介されています。

ちなみに、この不具合が確認されているのは『Windows 10 1903以降』ということです。

皆さん、こんにちは。

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

今朝の報道によりますと、Apple（アップル）が次期『iOS』にある変更を加える可能性が浮上しています。

iOS 14でデフォルトAppが変更可能かも

今朝の報道で伝えられているのは、『iOS』の次期バージョン『iOS 14』においてデフォルトのブラウザやメーラーがApple純正の『Safari』などから変更を可能にする機能を検討しているという情報です。

ご承知の通り『iOS』にプレインストールされたアプリは他のサードパーティ製アプリに変更することが許されていません。

しかし、これを次期バージョンの『iOS 14』あたりで変更を可能にすることを検討していることが伝えられています。

この背景には『独占禁止法違反』の可能性を懸念することも伝えられています。

現に、『macOS』においてはデフォルトアプリケーションの変更が可能になっているため、『iOS』においてもデフォルトアプリケーションの変更を可能にすることは確率的に高いかもしれません。

これが実現したとしても、私の場合、まずメーラーは変更しない可能性が高いです。

デスクトップでは『Thunderbird』、『iOS（iPhone）』ではApple純正の『メールソフト』を使用していますが何も不都合を感じていません。

ブラウザも変更しないかもしれません。

同期をしている方にとっては便利かもしれませんが、私にとってはどちらでもよい機能です。

それよりはもっと驚く機能を搭載してもらった方がありがたいですね。

皆さん、こんにちは。

業務改善を行う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・業務コンサルタント、高橋です。

さて、今日は『Google Chrome』の『Software Reporter Tool』に関する続編です。

Software Reporter Toolが無効化されない

先月に投稿した『CPUを大量使用する○○な機能』では、

以前のバージョンではChromeの再起動後には無効化したものが元に戻って有効化されてしまっていたようですが、現在の最新バージョン『Chrome 76』においては無効化されたままになります。

と書きましたが、すみませんm(_ _)m、間違っていたようです。

これ、機能して欲しくない方にとっては定期的に強制的な無効化を行う必要があります。

＜定期的な無効化＞

前回の記事で『Software Reporter Tool』の強制的な無効化を以下のようにご紹介しました。

１．c:\Users\（ユーザー名）\AppData\Local\Google\Chrome\User Data\SwReporter\（バージョン）の場所に『software_reporter_tool.exe』というアプリケーションファイルを見つけます。

２．『software_reporter_tool.exe』のプロパティ ⇒ 『セキュリティ』タブ ⇒ 詳細設定 ⇒ 継承の無効化 ⇒ 『このオブジェクトから継承されたアクセス許可をすべて削除します。』をクリック ⇒ 適用（OK）

この『（バージョン）』というのが『定期的に強制的な無効化』を行う必要があるという意味です。

つまり、『Software Reporter Tool』は『バージョン別』に存在しているようで、『Google Chrome』がメジャーアップデートされると別の新しいフォルダに生成されます。

従って、メジャーバージョンアップした際は新しいフォルダの『Software Reporter Tool』を強制的に無効化しないと『Software Reporter Tool』が機能してしまうことになります。

ある意味迷惑な機能にも思えますが、仕様が変わらない限り何ともならないでしょう。

疑問に思いタスクマネージャーを確認すると、CPUの使用率が100%に達しようとしていました。

皆さん、こんにちは。

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

さて、冒頭に書いた出来事は私が実際に体験したものなのですが、CPUに負荷をかけていたのはブラウザの『Google Chrome』にある機能が起こしていたものでした。

CPUを大量使用するChromeの機能とは

『Google Chrome』には、『有害なソフトウェア』、『システム設定』、『プロセス』について詳細なレポートをGoogleに送信する機能があります。

『Software Reporter Tool』というものです。

本来はそのまま有効にしておいた方が良い気もしますが、流石にCPUの使用率が大き過ぎ、CPUファンがうなりをあげて回転するようでは少々問題がある気もします。

では、もしこの『Software Reporter Tool』を無効にしてCPUへの負荷を抑えたい場合はどのようにしたら良いか？

＜Software Reporter Toolの無効化＞

『Software Reporter Tool』を無効にしておきたい場合は以下の手順で無効化できます。

Chromeの設定 ⇒ 詳細設定 ⇒ リセットとクリーンアップ ⇒ パソコンのクリーンアップ ⇒ 詳細なレポートをGoogleに送信するをオフにする

これで『Software Reporter Tool』が無効化されます。

以前のバージョンではChromeの再起動後には無効化したものが元に戻って有効化されてしまっていたようですが、現在の最新バージョン『Chrome 76』においては無効化されたままになります。

＜Software Reporter Toolの強制的な無効化＞

現状は一度無効化にしておけば再起動後に元に戻って有効化されてしまうことはないのですが、次回以降のアップデートで同様の現象が出てしまう可能性がないわけではありません。

そのような場合、『Software Reporter Tool』を強制的に無効化してしまう方法もあります。

１．c:\Users\（ユーザー名）\AppData\Local\Google\Chrome\User Data\SwReporter\（バージョン）の場所に『software_reporter_tool.exe』というアプリケーションファイルを見つけます。

２．『software_reporter_tool.exe』のプロパティ ⇒ 『セキュリティ』タブ ⇒ 詳細設定 ⇒ 継承の無効化 ⇒ 『このオブジェクトから継承されたアクセス許可をすべて削除します。』をクリック ⇒ 適用（OK）

これで強制的に『Software Reporter Tool』が無効化されます。

この『継承の無効化』に関しては、『継承の有効化』を行うことで元に戻すことも可能です。

ちなみに、『Windows Update』もCPU使用率は結構高いです。

皆さん、こんにちは。

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

金融機関や大手企業においては絶対と言って良い程採用されている『EV（Extended Validation） SSLサーバ証明書』ですが、この証明書によってURLバーに表示される組織名が間もなく消えてしまいます。

グリーンバーが間もなく消えます

『EV SSLサーバ証明書』の場合、取得には登記簿の提出などの要件があることから『本物』であることを『グリーンバー』として表示し、安心材料の一つとなっていました。

しかし、米国では州を変えて申請することで既知の企業と同じ組織名を表示する『EV SSLサーバ証明書』が作れてしまうという落とし穴があったとされています。

（これ、日本においても会社法上、同一商号は最小行政区ですら要件次第では登記可能ですから同じようなことが言えるとは思いますが。。。）

つまり、『EV SSLサーバ証明書』で組織名が表示されていても『偽物』の場合があり得てしまうということです。

このようなことからGoogleは一定のテストを行ったようで、結果的には来月リリース予定の『Google Chrome 77』からは『グリーンバー』を表示しない仕様へ変更する予定をしています。

（詳細情報での組織名確認は可能です。）

また、ブラウザへの仕様変更は『Firefox』でも同じように『グリーンバー』を表示しない方向で進めているようで、iOSにおける『Safari』は既に非表示になっています。

今後の対策としては、ブラウザの機能にある『セーフブラウジング』やセキュリティソフトに搭載されている同様の機能を活用していくことで被害を防ぐことになるのかもしれません。

皆さん、こんにちは。

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

冒頭に『それが必要なくなるかもしれません』という書き方をしましたが、実際にはブラウザが『Google Chrome 76』であれば『Lazy Load』や『lazysizes』といったものは必要なくなりました。

『Google Chrome 76』において『ネイティブlazy-load』をサポートするようになったのです。

JSなしで画像が遅延読込み可能に

『ネイティブlazy-load』はどうやら開発版のGoogle Chrome（Canary）で試験的に運用されていたようで、今回『Google Chrome 76』から正式にサポートされるようになりました。

ブラウザでサポートしてくれますので『<img>タグ』に『loading属性』を追加すれば機能してくれます。

『<img>タグ』だけでなく『<iframe>タグ』でも『loading属性』は機能します。

例えば、

<img src=”example.jpg” alt=”例” height=”500″ width=”500″>というコードの場合

<img src=”example.jpg” loading=”lazy” alt=”例” height=”500″ width=”500″>

とするだけです。

この『loading属性』は『lazy』を含めて3種類あります。

『loading=”lazy“』：lazy-loadを必ず適用し、画像が近づくとそれを読み込む。

『loading=”eager“』：lazy-loadを適用せず、ページと同時に画像を読み込む。

『loading=”auto“』：lazy-loadするかはブラウザに判断を任せる。

また、値がなく属性だけの場合は『auto』が適用されるとなっています。

Google Chromeを使っているユーザーは多いですから、JavaScriptを外してこのパターンに変更してしまっても良いのかもしれません。

ちなみに、SEOへの影響はないようです。

Googleが行っていることなので影響があっても困りますが。。。

皆さん、こんにちは。

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

既に『TLS1.0』と『TLS1.1』は多くのサービスで終了がアナウンスされており、現在の中心は『TLS1.2』となります。

しかし、それよりももっとセキュリティ的に安全で高速なのは『TLS1.3』での通信です。

TLS1.3対応で安全で高速な通信が間もなく

『Google Chrome』や『Mozilla Firefox』など、主要なブラウザでは既に『TLS1.3』に対応済みですが、ホストとなるサーバ側の方は一部のサーバが『TLS1.3』に対応し始めた程度の状況で、多くは未だ『TLS1.2』の状態です。

この『TLS1.3』は『TLS1.2』に比べてセキュリティ面、速度面の両面にて改善されている『暗号化通信プロトコル』であるため、早い段階で様々なところで対応がされることが望ましいわけですが、ホスト以外にも少々引っかかってしまう可能性があるものがあります。

それはセキュリティソフトです。

多くのセキュリティソフトでは各Webサイト（ページ）にブラウザからアクセスする際の通信を保護する機能が付いていますが、その部分が未だ『TLS1.2』までしか対応していないものがあります。

そのような場合、よく閲覧する『信頼できる』Webサイト（ページ）が『TLS1.3』に対応しているならばそれをチェック対象から外して通信を行うしかありません。

おそらく、各セキュリティソフトの次のバージョンにおいては間違いなく『TLS1.3』に対応したものがリリースされるはずですから、もう間もなくで環境が整ってくるのではないかと思われます。